IpcReceiver hangs indefinitely on MacOS when other process ends

[sunjay]

I have some code that calls IpcReceiver::recv(). I expect that it will block and then eventually send IpcError::Disconnected once the other process ends, but I'm finding that on MacOS it just hangs the process and continues to wait forever.

Steps:

1. call recv()
2. allow the other process to end
3. the recv() call will never return

One important detail is that I'm calling process::exit to end the process. That means that the drop code may not be run. I have tried manually dropping it with drop, but that has not fixed the problem.

This code works fine on other platforms.

[jdm]

Is this the same problem described by #201?

[jdm]

Mm, I guess that issue is referring to the accept() operation specifically, while this is just a standard IpcReceiver::recv.

[jdm]

I wonder if this is a symptom of #262?

[sunjay]

Is this the same problem described by #201?

No, I don't think so. Like you said, this is just a standard IpcReceiver::recv.

I wonder if this is a symptom of #262?

It might be. I am creating the IpcOneShotServer on Process A and then waiting for an IpcSender from Process B. Process B is the one that ends and Process A is the one that hangs forever on the call to recv().

[gterzian]

I've also noticed a similar behavior via the ROUTER, where it appeared like the route would never be removed, even when the last corresponding sender would have been dropped(the router removes the route when the receiver dis-connects).

[gterzian]

I have tried manually dropping it with drop, but that has not fixed the problem.

Yes I can confirm.

The workaround is to send an explicit message signalling exit, as opposed to rely on the drop behavior(it's also a good way to isolate the problem further, since if sending the explicit message doesn't help, the problem might be somewhere in the business logic).