This seems like a lot of work to do when you have signalfd, no? That + async and non blocking I/O should create the basis of a simple thread cancellation mechanism that exits pretty immediately, no?
As I note in the blog post in various places if one can organize the code so that cancellation is explicit things are indeed easier. I also cite eventfd as one way of doing so. What I meant to convey is that there's no easy way to cancel arbitrary code safely.
I have been using signalfd + epoll where it looks like I could use eventfd instead (or just epoll_pwait). Is there a significant benefit to one approach over another? I suspect eventfd might be more efficient (and doesn't use up a signal handler... when are we going to get SIGUSR3 ?!?).
I don't really get it. There are two possibilities here:
* You control all the IO, and then you can use some cooperative mechanism to signal cancellation to the thread.
* You don't control IO code at the syscall level (e.g. you're using some library that uses sockets under the hood, such as a database client library)... But then it's just obvious you're screwed. If you could somehow terminate the thread abruptly then you'll leak resources (possibly leaving mutexes locked, as you said), or if you interrupt syscalls with an error code then the library won't understand it. That's too trivial to warrant a blog post fussing about signals.
The only useful discussion to have on the topic of thread cancellation is what happens when you can do a cooperative cancel, so I don't think it's fair to shoot that discussion down.
