Revert "Return error when exception was raised after main thread fini…

[yamt]

…shes (#2169)"

This reverts commit 71d43f3.

for some reasons, the original commit assumes a trap should win over an exit even if the former is 1 second behind the latter. i don't see any reason it should. in that case, the expected behavior is that the exit likely wins and the other thread won't even reach the code to raise a trap.

[wenyongh]

LGTM

[eloparco]

for some reasons, the original commit assumes a trap should win over an exit

Is that because a return from main gets compiled to proc_exit() with wasi-sdk? If that's the case, it makes sense. When I wrote the test, I wasn't considering that.

[yamt]

for some reasons, the original commit assumes a trap should win over an exit

Is that because a return from main gets compiled to proc_exit() with wasi-sdk? If that's the case, it makes sense. When I wrote the test, I wasn't considering that.

how a return from main should behave is defined by C standard.
you don't need to look at the specific implementation in wasi-sdk to write a C-level test.

[wenyongh]

@eloparco Is the PR good to you? Shall we merge it?

[loganek]

LGTM

[eloparco]

Is that because a return from main gets compiled to proc_exit() with wasi-sdk?

Actually no, that's not the case, that's why the test was returning 1.

The wasi-threads proposal doesn't state that the process ends if the main thread ends (as for phtreads). So in the test in the PR I would expect the main thread to end and the process to terminate after the spawned thread finishes. Since the thread raises a trap, I would expect it to be propagated.
Not sure if that can be considered an implementation detail.

[yamt]

Is that because a return from main gets compiled to proc_exit() with wasi-sdk?

Actually no, that's not the case, that's why the test was returning 1.

The wasi-threads proposal doesn't state that the process ends if the main thread ends (as for phtreads). So in the test in the PR I would expect the main thread to end and the process to terminate after the spawned thread finishes. Since the thread raises a trap, I would expect it to be propagated. Not sure if that can be considered an implementation detail.

see WebAssembly/wasi-threads#21
the option b is what wasi-libc assumes.

[eloparco]

So wasi-libc doesn't compile the return from main as proc_exit. The runtime decides whether or not to wait for all threads to finish. In WAMR implementation, we wait for them to finish.

In this scenario, shouldn’t the exception from the spawned thread be propagated and returned even if the main thread has already finished? That's what #2524 is reverting.

[eloparco]

see WebAssembly/wasi-threads#21
the option b is what wasi-libc assumes.

Ok not sure that's what's currently implemented, last time I checked iwasm was waiting for all threads to finish. Worth adding an assert(false) at the end of the spawned thread execution in trap_after_main_thread_finishes.c to validate the behavior.

[yamt]

see WebAssembly/wasi-threads#21
the option b is what wasi-libc assumes.

Ok not sure that's what's currently implemented, last time I checked iwasm was waiting for all threads to finish. Worth adding an assert(false) at the end of the spawned thread execution in trap_after_main_thread_finishes.c to validate the behavior.

see also #2529

we should test how it should be, not what it happens to be implemented.

[eloparco]

we should test how it should be, not what it happens to be implemented.

But this is WAMR repository not the wasi-threads one. I think if we decide for a specific implementation we have to document it and test it, otherwise users wouldn't know what to expect.

[yamt]

we should test how it should be, not what it happens to be implemented.

But this is WAMR repository not the wasi-threads one. I think if we decide for a specific implementation we have to document it and test it, otherwise users wouldn't know what to expect.

i'm not sure if i follow your logic.
do you mean wamr should behave differently?

[eloparco]

i'm not sure if i follow your logic.
do you mean wamr should behave differently?

That whatever we implement we should update the test to check it.

for some reasons, the original commit assumes a trap should win over an exit even if the former is 1 second behind the latter.

The original commit was working as a. from WebAssembly/wasi-threads#21, so the main thread was exiting without stopping the spawned thread. When the spawned thread raises the exception afterwords, it gets propagated and returned to the host.

What I see from #2529 is that you want to implement it as b.

[yamt]

for some reasons, the original commit assumes a trap should win over an exit even if the former is 1 second behind the latter.

The original commit was working as a. from WebAssembly/wasi-threads#21, so the main thread was exiting without stopping the spawned thread. When the spawned thread raises the exception afterwords, it gets propagated and returned to the host.

it's broken.
regardless options in WebAssembly/wasi-threads#21,
a return from main() should be an equivalent of exit() as in C standard.