ipc-channel icon indicating copy to clipboard operation
ipc-channel copied to clipboard

IpcReceiver hangs indefinitely on MacOS when other process ends

Open sunjay opened this issue 5 years ago • 7 comments

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.

sunjay avatar May 28 '20 01:05 sunjay

Is this the same problem described by #201?

jdm avatar May 28 '20 01:05 jdm

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

jdm avatar May 28 '20 01:05 jdm

I wonder if this is a symptom of https://github.com/servo/ipc-channel/issues/262?

jdm avatar May 28 '20 01:05 jdm

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().

sunjay avatar May 28 '20 01:05 sunjay

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 avatar Jun 16 '20 06:06 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).

gterzian avatar Jun 16 '20 06:06 gterzian