Fix test_pthread_dlopen_many

[sbc100]

When a thread sync was cancelled (due to a thread exit prior to performing the
task) we were treating that as an error, but we should treat that as success.

I was able to reproduce the issue by running this test a few times in
a row. I confirmed that it did not happen in 160 runs after this fix.

Fixes: #18887

[dschuff]

Can you expand the commit message a little bit to say what was going wrong and how PR fixes it?

[kripken]

Makes sense. Where in the test does a cancel occur, though? I can't seem to find that.

[dschuff]

thanks for the explanation, this makes sense.

[sbc100]

Makes sense. Where in the test does a cancel occur, though? I can't seem to find that.

I add some comments and elaborated in the PR description.

The test just start a lot of threads that don't do much and just exit when they are done so its not surprising that we see a thread exit when another one is loading.

[kripken]

Hmm, but how can a thread exit before it finishes the task? That's what I'm not seeing in that test. It looks like they each do some straightforward work, so I'd expect them to all finish normally, despite their large number.

[dschuff]

I think it's not that they aren't finishing (their own task) normally, it's that they are finishing their own task and exiting before they finish the task of loading all the dlls that were opened on other threads while they were running. In that case the task of loading more dlls is cancelled because the thread is done. But that was being reported as a failure.

[kripken]

Oh, I see, thanks! Makes sense to me now.

[sbc100]

Hmm, but how can a thread exit before it finishes the task? That's what I'm not seeing in that test. It looks like they each do some straightforward work, so I'd expect them to all finish normally, despite their large number.

Basically we dispatch "dlsync" requests to all threads.. But if a thread is just about to exit, the exit might happen before the thread performs the task. In that case it doesn't matter than the thread is not in sync because is no longer running. All threads sync up on startup anyway.

[tlively]

@sbc100, if you want, you could also simplify this code by using emscripten_proxy_promise instead of emscripten_proxy_callback.