In a discussion yesterday with @sbc100 and @sunfishcode, we considered whether it might be necessary to add a second API call to the wasi-threads proposal to support early exit from threads. Since exception support is neither standardized nor widespread, it is impossible for a child thread to "early exit" and continue execution in the exported thread entry point, wasi_thread_start. This entry point can contain code responsible for important tasks, such as notifying joiners that the thread is complete (e.g., in wasi-libc), and possibly others such as cleaning up any TLS allocations.
One suggestion was to implement pthread_exit in wasi-libc using a new API call, wasi_thread_exit. But consider what happens when wasi_thread_exit is called: it could presumably dispose of the child thread from the host side, but it would not really have access to execute the cleanup code at the end of was_thread_start (e.g., the join notify instructions). To properly support pthread_exit it may be necessary to do more, e.g., exporting a second function from threaded modules, wasi_thread_stop.
Any additional thoughts on this?
One side issue we discussed is that traps and calls to exit in child threads take down the entire program. This eliminates a whole other set of problems and we should probably document this in the README.
In a discussion yesterday with @sbc100 and @sunfishcode, we considered whether it might be necessary to add a second API call to the
wasi-threadsproposal to support early exit from threads. Since exception support is neither standardized nor widespread, it is impossible for a child thread to "early exit" and continue execution in the exported thread entry point,wasi_thread_start. This entry point can contain code responsible for important tasks, such as notifying joiners that the thread is complete (e.g., in wasi-libc), and possibly others such as cleaning up any TLS allocations.One suggestion was to implement
pthread_exitin wasi-libc using a new API call,wasi_thread_exit. But consider what happens whenwasi_thread_exitis called: it could presumably dispose of the child thread from the host side, but it would not really have access to execute the cleanup code at the end ofwas_thread_start(e.g., the joinnotifyinstructions). To properly supportpthread_exitit may be necessary to do more, e.g., exporting a second function from threaded modules,wasi_thread_stop.Any additional thoughts on this?
One side issue we discussed is that traps and calls to
exitin child threads take down the entire program. This eliminates a whole other set of problems and we should probably document this in theREADME.