[rostayob]

This is noted in the blog post, but the problem is that sometimes you don't have the freedom to do so. See this sidenote and the section next to it: https://mazzo.li/posts/stopping-linux-threads.html#fn3 .

[quietbritishjim]

I'll admit: I didn't see that.

But I also disagree with it. Yes, the logical conclusion of starting down that path is that you end up with full on use of coroutines and some IO framework (though I don't see the problem with that). But a simple wrapper for individual calls that is recv+cancel rather than just recv etc is better than any solution mentioned in the blog post.

The fact is, if you want to wait for more than one thing at once at the syscall level (in this case, IO + inter thread cancellation), then the way to do that is to use select or poll or something else actually designed for that.

[cyberax]

I had this problem, and I solved it by farming the known-blocking syscalls to a separate thread pool. Then the calling thread can just abandon the wait. To make it a bit better, you can also use bounded timeouts (~1-2 seconds) with retries for some calls like recvfrom() via SO_TIMEOUT so that the termination time becomes bounded.

This is probably the cleanest solution that is portable.

[naasking]

Then those thread pool threads have to be careful not to take locks and other scarce resources that aren't cleaned up then, no?