How to stop Linux threads cleanly

I'm reminded of Raymond Chen's many many blogs[1][2][3](there are a lot more) on why TerminateThread is a bad idea. Not surprised at all the same is true elsewhere. I will say in my own code this is why I tend to prefer cancellable system calls that are alertable. That way the thread can wake up, check if it needs to die and then GTFO.

[1] https://devblogs.microsoft.com/oldnewthing/20150814-00/?p=91...

[2] https://devblogs.microsoft.com/oldnewthing/20191101-00/?p=10...

[3] https://devblogs.microsoft.com/oldnewthing/20140808-00/?p=29...

there are a lot more, I'm not linking them all here.

For interrupting long-running syscalls there is another solution:

Install an empty SIGINT signal handler (without SA_RESTART), then run the loop.

When the thread should stop:

* Set stop flag

* Send a SIGINT to the thread, using pthread_kill or tgkill

* Syscalls will fail with EINTR

* check for EINTR & stop flag , then we know we have to clean up and stop

Of course a lot of code will just retry on EINTR, so that requires having control over all the code that does syscalls, which isn't really feasible when using any libraries.

EDIT: The post describes exactly this method, and what the problem with it is, I just missed it.

If you can swing it (don't need to block on IO indefinitely), I'd suggest just the simple coordination model.

  * Some atomic bool controls if the thread should stop or not;
  * The thread doesn't make any unbounded wait syscalls;
  * And the thread uses pthread_cond_wait (or equivalent C++ std wrappers) in place of sleeping while idle.

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?

libcurl dealt with this a few months ago, and the sentiment is about the same: thread cancellation in glibc is hairy. The short summary (which I think is accurate) is that an hostname query via libnss ultimately had to read a config file, and glibc's `open` is a thead cancellation point, so if it's canceled, it'll won't free memory that was allocated before the `open`.

The write-up is on how they're dealing with it starts at https://eissing.org/icing/posts/pthread_cancel/.

Off-Topic: I surprised myself by liking the web site design. Especially the font.

Previously: https://news.ycombinator.com/item?id=38908556

And somehow just a day ago: https://news.ycombinator.com/item?id=45589156

This was a fun read, I didn't know about rseq until today! And before this I reasonably assumed that the naive busy-wait thing would typically be what you'd do in a thread in most circumstances. Or that at least most threads do loop in that manner. I knew that signals and such were a problem but I didn't think just wanting to stop a thread would be so hard! :)

Hopefully this improves eventually? Who knows?

this stuff always seemed a mess. in practice i've always just used async io (non-blocking) and condition variables with shutdown flags.

trying to preemptively terminate a thread in a reliable fashion under linux always seemed like a fool's errand.

fwiw. it's not all that important, they get cleaned up at exit anyway. (and one should not be relying on operating system thread termination facilities for this sort of thing.)

pthread cancelation ends up not being the greatest, but it's important to represent it accurately. It has two modes: asynchronous and deferred. In asynchronous mode, a thread can be canceled any time, even in the middle of a critical section with a lock held. However, in deferred mode, a thread's cancelation can be delayed to the next cancelation point (a subset of POSIX function calls basically) and so it's possible to make that do-stuff-under-lock flow safe with cancelation after all.

That's not to say people do or that it's a good idea to try.

> How to stop Linux threads cleanly

kill -HUP ?

while (true) { if (stop) { break; } }

If there only was a way to stop while loop without having to use extra conditional with break...