Don't proxy entire abort function back to the main thread

[sbc100]

It turns out proxying abort has several issues:

1. If we do stuff like proxing during the call to abort
   it can allocate stack and heap space which might not
   be possible by the time abort is called.
2. All the other calls to abort that don't go via the library
   function (calls to abort directly from JS) are not proxied
   meaning we get inconsistent proxying.

Instead I use postMessage to send just the onAbort and do
the rest of the abort in the local thread.

The exception will end up triggering the worker.onerror so
go entire application will still get torn down.

[kripken]

Is this needed? As we proxy exceptions to the main thread, wouldn't just throwing an exception as abort does do all we need?

[sbc100]

The use case in #11345 specifically requires that onAbort is called.

In many cases the Module object that that includes the onAbort function only exists on the main thread.

[kripken]

Please add a comment here, maybe

// abort() must be proxied, but we avoid the normal method since
// the runtime may not be in a good enough state to support that.
// Instead, it is proxied using postMessage, see library_pthread.js.

[sbc100]

Its not that abort needs to be proxied its just the onAbort callback. I will add a comment.

[sbc100]

(Is there an existing test for this?)

Yes, the test I added back in #14669 tests exactly this. It injects the onAbort handler during preInit which means that handler will only exist on the main thread and therefore must be invoked there:

emscripten/tests/test_core.py

Lines 2356 to 2360 in 8cbca51

	@node_pthreads
	def test_pthread_abort(self):
	self.set_setting('PROXY_TO_PTHREAD')
	self.add_pre_run("Module.onAbort = function() { console.log('onAbort called'); }")
	self.do_run_in_out_file_test('pthread/test_pthread_abort.c', assert_returncode=NON_ZERO)

[kripken]

Sounds good.

[kripken]

(Is there an existing test for this?)