Follow-up changes for blocking unamed_socket

[tiif]

Since I left some comments on why the initial throw_unsupported is unreachable, I will just push the follow-up changes from #4072 to here. :)

@rustbot author

[tiif]

Currently the diagnostic already shows deadlock on write because we wake up the blocked write thread only if the fd blocked on write is not closed:

Relevant code snippet:

miri/src/shims/unix/unnamed_socket.rs

Lines 304 to 314 in 3eea5b8

	if let Some(peer_fd) = self_anonsocket.peer_fd().upgrade() {
	ecx.check_and_update_readiness(&peer_fd)?;
	let peer_anonsocket = peer_fd.downcast::<AnonSocket>().unwrap();
	// Unblock all threads that are currently blocked on peer_fd's write.
	let waiting_threads =
	std::mem::take(&mut *peer_anonsocket.blocked_write_tid.borrow_mut());
	// FIXME: We can randomize the order of unblocking.
	for thread_id in waiting_threads {
	ecx.unblock_thread(thread_id, BlockReason::UnnamedSocket)?;
	}
	};

This is acceptable, but I wanted to try if it is possible to let the diagnostic point to close and tell the user that "this thread never wakes up because of the close here".

EDIT: On other note, this also means that throw_unsupported in anonsocket_write is unreachable.

[RalfJung]

Currently the diagnostic already shows deadlock on write because we wake up the blocked write thread only if the fd blocked on write is not closed:

There's still an odd throw_unsupported in that logic that we should get rid of. Either it is unreachable and should become an assert, or else you can adjust the test to reach it. (I think it is reachable.)

Improving the diagnostics is nice, but getting rid of that throw_unsupported is the more important part IMO.

[tiif]

After thinking a little bit more, I am inclined to think that the unsupported for unnamed_socket read/write might be both unreachable, so I might remove both. But I will add test(s) to reconfirm it.

[tiif]

The unsupported in anonsocket_read should be unreachable too because in order to hit that path, it needs to fulfil these conditions:

1. read must be unblocked (after previously blocked)
2. The fd blocked (in this test, it is fds[1]) on read is closed.

But after the fd blocked on read (fds[1]) is closed, it is impossible to have a success write on fds[0], so read is never unblocked, condition 1. couldn't be fulfilled.

[RalfJung]

Oh, right... we only wake up a thread if we successfully upgraded the weak ref stored in the peer, and then ofc the weak ref stored in the callback also must still be valid.

[tiif]

These are duplicates of #4112, so I will just close this.