Sending a sender over a channel and immediately receiving from the corresonding receiver intermittently fails on linux

[jdm]

#179
This is one of our longest-existing and most distributed intermittent failures in Servo's automated tests.

[pshaughn]

ipc-channel/src/platform/unix/mod.rs

Lines 1018 to 1025 in 84a1483

	let result = recvmsg(fd, &mut self.msghdr, 0);
	let result = if result > 0 {
	Ok(result as usize)
	} else if result == 0 {
	Err(UnixError::ChannelClosed)
	} else {
	Err(UnixError::last())
	};

If the error we get is an EINTR coming from here, we should retry the recvmsg, not abort. From what I'm reading, EINTR can happen here at random when the process receives basically any UNIX signal.
An example of a loop that exists for the sake of retrying on EINTR, from wine: https://github.com/wine-mirror/wine/blob/9642f35922b79cebacdc774eb54619e389ccd531/dlls/ntdll/server.c#L793
A more Rust-specific warning about this: https://people.gnome.org/~federico/blog/rust-libstd-syscalls-and-errors.html

[pshaughn]

I jammed an assert that it wasn't EINTR in there and started running the test from #179 in a loop in a bunch of terminals but I'm not getting either that test's failure or my own assertion failure; my environment (a Mint VM on Windows host) might not be vulnerable to whatever problem this is. Someone who can reproduce this easily should see which Unix error code it is.
(If it is this, every blocking libc call that mentions EINTR as a possible error in its man page should have similar retry logic applied, it's not exclusive to recvmsg.)