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.