Hi Christian, > > > > Emscripten's fiber does not support submitting coroutines to other > > > > threads. So this commit modifies hw/9pfs/coth.h to disable this behavior > > > > when compiled with Emscripten. > > > > > > The lack of being able to dispatch a coroutine to a worker thread is one > > > thing, however it would probably still make sense to use fibers in 9pfs as > > > replacement of its coroutines mechanism. > > > > > > In 9pfs coroutines are used to dispatch blocking fs I/O syscalls from main > > > thread to worker thread(s): > > > > > > https://wiki.qemu.org/Documentation/9p#Control_Flow > > > > > > If you just remove the coroutine code entirely, 9p server might hang for > > good, > > > and with it QEMU's main thread. > > > > > > By using fibers instead, it would not hang, as it seems as if I/O > > syscalls are > > > emulated in Emscripten, right? > > > > Thank you for the feedback. Yes, it would be great if Emscripten's fiber > > could be used to address this limitation. Since Emscripten's fiber is > > cooperative, I believe a blocking code_block can still block the 9pfs server > > unless an explicit yield occurs within it. I'll continue exploring better > > solutions for this. Please let me know if I'm missing anything. > > As far as I understand it, the I/O syscalls are emulated, and when being > called by fibers, blocking syscalls would imply to yield under the hood, > without explicit yield by application that is. > > If that's true, it would only require little code changes for this to work.
Thank you for the information. Yes, I/O syscalls are emulated by Emscripten. While I haven't found documentation or implementation details on whether Fibers implicitly yield on blocking syscalls, I'll continue to explore this approach. > > Let my answer my own question: I just checked the wasi sources. The errno > > values are hard coded by the wasi API, consistent over systems. So the current > > mapping of this patch is wrong. macOS uses a different mapping than the wasi > > API. > > > > https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/__errno_values.h > > > > https://github.com/emscripten-core/emscripten/blob/4af36cf80647f9a82be617a0ff32f3e56f220e41/system/include/wasi/api.h#L116 > > > > So please use a correct mapping as defined in that header file. > > > > /Christian > > > > > Alternatively 9p2000.u protocol variant could be used for Emscripten. Not > > > ideal, as this 9p protocol version is somewhat a legacy protocol from QEMU > > > perspective, reduced performance, less reliable, but it transmits error > > > strings to client which it can map to correct errno values by itself. Linux 9p > > > client uses a hash map for this errno translation of 9p2000.u error strings. > > Stupid me. That's host errno -> Linux errno translation. So your values are > obviously correct, sorry! > > However still worth comparing the Linux vs. wasi header files on this. > > And I would avoid duplicating the macOS translation code. Instead I would just > do a one-line change: > > #elif defined(CONFIG_DARWIN) || defined(EMSCRIPTEN) > ... > > And probably leave a comment with a link to the wasi API header file there, so > in case new errno translations are added for macOS, that people also check > whether those macros exist in the wasi header file as well. Thanks again for the suggestion. I'll apply this change in the next version of the series.
