How should threads early-exit?

[abrown]

Threads can exit by running out of instructions to execute or by trapping, but trapping aborts all other threads. In the case the user wants to early-exit a thread, e.g., pthread_exit, but not end execution elsewhere, how should we propose to do so? In the section about thread exits, we suggest two options:

1. rely on the exception handling proposal
2. add a new instruction: thread.exit

[conrad-watt]

A couple of thoughts:

I wouldn't necessarily expect trapping to abort all other threads (and sorry that I missed commenting on this section earlier). I think there's a design question as to whether a thread trapping aborts all threads that it created.

Another potential solution that avoids a dependency on EH would be to transform control flow so that early-exit can be done programmatically - this would be like a simpler version of the existing asyncify transformation. That being said, I think that the EH solution is quite nice since it also allows well-behaved cleanup.

[rossberg]

I'm also surprised by the assumption that a trap aborts all other threads. That obviously isn't the case with web worker threads. I'm not even sure what "all other threads" should mean, since a trap in one "application" surely shouldn't take down threads from another application. So this supposes some kind of implicit thread grouping?

I'd view a trap as an uncatchable internal form of exception, so it propagates in a structured manner.

[abrown]

Oh, maybe that it isn't clear then: "all other threads" means all the threads spawned by a module. I thought when we discussed this a while back you were of the opinion (was it you?) that a trap in one part of a module — e.g., one of its spawned threads — leaves the entire module instance in an unrecoverable state and so we should tear down all the other threads.

[rossberg]

Modules are purely a code organisation mechanism. As such, module boundaries should never affect operational behaviour, otherwise steps like static linking or splitting a module would silently change behaviour. Hence, any form of thread grouping mechanism must be independent from modules. Preferably, there is no need for any grouping mechanism at all.

[sunfishcode]

If a thread traps and we don't shutdown other threads, the host doesn't have enough information to break locks in the guest, or to understand which threads are depending on other threads to notify them in the future, so it doesn't seem possible to reliably avoid leaks, deadlocks, and unbounded useless work.

If we don't want grouping in the spec, one option is that if one thread traps, hosts can trap all threads in the store.

[sunfishcode]

I discussed this with @lukewagner, and he convinced me that leaving the decision of what to do to hosts is best for now.

That still leaves the question of what to do about programs that want threads to keep running after the main thread exits. What if we implement that in libc, by having pthread_exit on the main thread block on a condition variable which gets notified when threads exit, so that it holds the main thread alive until the last user thread has exited?

[yamt]

i agree module boundary should not be used for grouping.

what wasi-threads uses is:

• the first thread (eg. the entry point of the program) starts with a group which only contains the thread
• if a thread spawns another thread, they belong to the same group.

i guess we can use a similar grouping here.

[yamt]

if i understand correctly, this github conversation is about early-exit, which is, how to allow a thread to terminate itself gracefully.
(eg. how to implement pthread_exit.)

if a trap should terminate "other threads in the group", or if a grouping is necessary at all, is a separate topic i guess.