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

[glyn]

The problem still reproduces. The following integration test fails on macOS, but passes on Linux and Windows:

/// Test spawing a process which then acts as a client to a
/// one-shot server in the parent process. The client sends
/// one message and terminates, but the server attempts to
/// receive a second message. This receive should fail
/// because the client has disconnected.
#[cfg(not(any(feature = "force-inprocess", target_os = "android", target_os = "ios")))]
#[test]
fn spawn_one_shot_server_client_which_exits_prematurely() {
    let executable_path: String = env!("CARGO_BIN_EXE_spawn_client_test_helper").to_string();

    let (server, token) =
        IpcOneShotServer::<String>::new().expect("Failed to create IPC one-shot server.");

    let mut command = process::Command::new(executable_path);
    let child_process = command.arg(token);

    let mut child = child_process
        .spawn()
        .expect("Failed to start child process");

    let (rx, msg) = server.accept().expect("accept failed");
    assert_eq!("test message", msg);

    let result = child.wait().expect("wait for child process failed");
    assert!(
        result.success(),
        "child process failed with exit status code {}",
        result.code().expect("exit status code not available")
    );

    // The error message differs on Windows ("Disconnected") and Unix/Linux ("disconnected").
    assert_eq!(
        rx.recv()
            .err()
            .expect("expected error was not returned")
            .to_string()
            .to_lowercase(),
        "disconnected"
    );
}