Open hly2019 opened 1 month ago
I think this is because the emscripten FS operations are all non-blocking, and this means all pipe's are effectively non-blocking.
If you make sure the write thread is finished before starting the read thread then I would hope this would work. I would possibly investing allowing some kind of blocking I/O, perhaps via ASYNCIFY, or perhaps allowing it only on threads, but that would be quite a large change.
Please include the following in your bug report:
Version of emscripten/emsdk: 3.1.54
Failing command line in full:
Hi, I was using the
pipe
in a multi-threading scenario. I found if I write a pipe in one thread, then read in another thread, it seems the process will not work as expected.In the following code, it uses a variable,
cnt
to count the number of"xy"
read from the pipe. Here,cnt
is expected to be100
because in the write end, we write"xy"
100 times to the pipe, and so does it perform in the native version.However, in the wasm execution, the result is not as expected as shown below. The value of
cnt
is not100
, and it even can't get a stable result (found to be 24, 22, 0, etc.), which seems to indicate a possible thread safety issue.It'd be great if you could check it. Thank you!
Code
Results
Here is the result of wasm and native execution. (For the wasm result, here it just shows a sample: here the result of wasm execution is actually not stable and could be various values.)