3 ms·

If your threads run "cooperative multi threading" task (e.g. rust tokio runtime, JS in general etc.) then this kinda is a non problem. Due to task frequently r

If your threads run "cooperative multi threading" task (e.g. rust tokio runtime, JS in general etc.) then this kinda is a non problem. Due to task frequently returning to the scheduler the scheduler can do "should stop" check there (also as it might be possible to squeeze it into other atomic state bit maps it might have 0 relevant performance overhead (a single is-bit-set check)). And then properly shut down tasks. Now "properly shut down tasks" isn't as trivial, like the "cleaning up local resources" part normally is, but for graceful shutdown you normally also want to allow cleaning up remote resources, e.g. transaction state. But this comes from the difference of "somewhat forced shutdown" and "grace full shutdown". And in very many cases you want "grace full shutdown" and only if it doesn't work force it. Another reason not to use "naive" forced only shutdown... Interpreter languages can do something similar in a very transparent manner (if they want to). But run into similar issues wrt. locking and forced unwinding/panics from arbitrary places as C. Sure a very broken task might block long term. But in that case you often are better of to kill it as part of process termination instead and if that doesn't seem an option for "resilience" reasons than you are already in better use "multiple processes for resilience" (potentially across different servers) territory IMHO. So as much as forced thread termination looks tempting I found that any time I thought I needed it it was because I did something very wrong else where.

PaulDavisThe1st 1y ago
user-space threads have entirely different semantics from kernel threads. both have their uses, but should generally not be conflated.
- dathinab 1y ago
  Concepts of cooperate multi threading, co-rutines etc. aren't limited to user space. Actually they out date the whole "async" movement or whatever you want to call it. Also the article is about user-space threads, i.e. OS threads, not kernel-space threads (which use kthread_* not pthread_* and kthreads stopping does work by setting a flag to indicate it's supposed to stop, wakes the thread and then waits for exit. I.e. it works much more close to the `if(stop) exit` example then any signal usage.
  - PaulDavisThe1st 1y ago
    The pthread API, defined by POSIX, and referred to in TFA's title as "linux threads", concerns kernel threads. Pthreads does not provide user-space threads in any implementation I am aware of, and is not intended to (though it likely could be done). The API is intended to allow a process to have multiple execution contexts that can be scheduled by the kernel independently.
    - dathinab 1y ago
      yes POSIX threads, i.e. user-space threads I think you have a very strange definition of "user-space", "kernel-space". kernel space is what runs _in_ the kernel, it doesn't involve pthreads (on any OS) and uses kthreads (on Linux). POSIX threads are user space threads. It doesn't matter that they are scheduled by the kernel, that is the norm for threads in user space. Also know as OS threads. What you probably mean with user-space threads are green threads. Which are build on one or more OS threads but have an additional scheduling layer which can schedule multiple green threads on one OS thread using some form of multiplexing scheme.
AtlasBarfed 1y ago
I'm unfamiliar with this, is "coop multithreading" basically equivalent to Windows 3.1 style coop multitasking, where a thread can hang the whole application by ... not cooperating? Does anyone here remember Windows 3.1?
- dathinab 1y ago
  yesn't both are forms of cooperative multi tasking/threading but there are a many differences about what you expect how exactly it is implemented and most relevantly you run the cooperative tasks on a pool of OS threads which are preempted, so a single thread hanging won't hang your whole application. And dev tooling has gotten much better since then, that helps a lot too. also Windows 3.1 kinda predates me, so no not really PS: And JS in the browser still uses cooperative multi tasking and the whole website hanging isn't exactly the norm ;) Partially because you can opt for preempted threads (worker) which also happend to not be good at handling termination. And partially because a lot of iff overhead logic is moved outside of web apps and into the browser itself (e.g. layout, rendering etc.). It's pretty common to setup one such worker and then use message passing to send work to it, but this means that between concurrent tasks there is no preemption and on way to handle arbitrary numbers concurrent requests with a very limited number of workers is to make each worker internally use cooperative multi tasking. So we are kind back at cooperative multi tasking on top of preempted OS threads.

PaulDavisThe1st 1y ago

user-space threads have entirely different semantics from kernel threads. both have their uses, but should generally not be conflated.

dathinab 1y ago
Concepts of cooperate multi threading, co-rutines etc. aren't limited to user space. Actually they out date the whole "async" movement or whatever you want to call it. Also the article is about user-space threads, i.e. OS threads, not kernel-space threads (which use kthread_* not pthread_* and kthreads stopping does work by setting a flag to indicate it's supposed to stop, wakes the thread and then waits for exit. I.e. it works much more close to the `if(stop) exit` example then any signal usage.
- PaulDavisThe1st 1y ago
  The pthread API, defined by POSIX, and referred to in TFA's title as "linux threads", concerns kernel threads. Pthreads does not provide user-space threads in any implementation I am aware of, and is not intended to (though it likely could be done). The API is intended to allow a process to have multiple execution contexts that can be scheduled by the kernel independently.
  - dathinab 1y ago
    yes POSIX threads, i.e. user-space threads I think you have a very strange definition of "user-space", "kernel-space". kernel space is what runs _in_ the kernel, it doesn't involve pthreads (on any OS) and uses kthreads (on Linux). POSIX threads are user space threads. It doesn't matter that they are scheduled by the kernel, that is the norm for threads in user space. Also know as OS threads. What you probably mean with user-space threads are green threads. Which are build on one or more OS threads but have an additional scheduling layer which can schedule multiple green threads on one OS thread using some form of multiplexing scheme.

AtlasBarfed 1y ago

I'm unfamiliar with this, is "coop multithreading" basically equivalent to Windows 3.1 style coop multitasking, where a thread can hang the whole application by ... not cooperating? Does anyone here remember Windows 3.1?

dathinab 1y ago
yesn't both are forms of cooperative multi tasking/threading but there are a many differences about what you expect how exactly it is implemented and most relevantly you run the cooperative tasks on a pool of OS threads which are preempted, so a single thread hanging won't hang your whole application. And dev tooling has gotten much better since then, that helps a lot too. also Windows 3.1 kinda predates me, so no not really PS: And JS in the browser still uses cooperative multi tasking and the whole website hanging isn't exactly the norm ;) Partially because you can opt for preempted threads (worker) which also happend to not be good at handling termination. And partially because a lot of iff overhead logic is moved outside of web apps and into the browser itself (e.g. layout, rendering etc.). It's pretty common to setup one such worker and then use message passing to send work to it, but this means that between concurrent tasks there is no preemption and on way to handle arbitrary numbers concurrent requests with a very limited number of workers is to make each worker internally use cooperative multi tasking. So we are kind back at cooperative multi tasking on top of preempted OS threads.