onAbort is scoped to Module and does not get called from a pthread

[DConmy]

Relevant doc... https://emscripten.org/docs/api_reference/module.html

If Module['onAbort'] is set on the browser thread, given that Module is not visible to the pthread, an abort(-1) or similar will not call the onAbort function.

I would have expected that pthread creation would/could copy the onAbort handler to the pthread via threadParams so that the handling would be inherited by worker threads.

As a workaround, I plan on setting onAbort in each of our threads.

[DConmy]

I confirmed that setting onAbort in the pthreads will then work.
Could the documentation be updated to clarify that the setting is required to be set per thread?

[sbc100]

I seems like perhaps abort should be proxied back the main thread and handled there.. since abort is supposed to bring down the entire program, not just one thread it seems like it should be handled centrally? @juj, what do you think?

If you have suggestions for the docs please feel free to send patches .. that docs are all stored in the .rst files in the docs directory.

[DConmy]

@sbc100 Handling on the main thread would be fine.
It is important that the stack get proxied to the main thread as well since that is important aspect of the abort context.

[DConmy]

There is value in having it on the thread too. In the case where there is thread context that could potentially be collected before final abort. I do understand that at the abort point, you probably can't trust much of your current state, though.

[juj]

SGTM to proxy onAbort back to main thread - just gate it out from MINIMAL_RUNTIME, as that does not have a Module.onAbort abstraction.

Although something to be mindful is that the wasm message queue can probably not be used for this, it may be in a corrupt state when we abort, so good old postMessage should be used instead.

[sbc100]

I just ran into this issue in test code where asserts (aborts) in pthreads don't bring down the application as expected.

See #12885.

So this issue really about abort() itself.

[trybka]

I ran into some related issues recently. I think you don't want to just proxy onAbort, but probably want an abortProcess (analogous to exitProcess) that actually terminates all threads, but doesn't run the ATEXIT handlers. Since Emscripten doesn't raise signals, _Exit and _exit are probably closer in this regard to abort, than to exit.

EDIT: Also note, that it is a bug for _Exit to call atexit handlers[1] (which it does today-- _exit, _Exit, and exit are all the same function)

[1] http://eel.is/c++draft/support.start.term#3