On Friday, April 11, 2025 12:47:29 PM CEST Kohei Tokunaga wrote: > 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. > > Missing > > > > errno = ENOTSUP; > > Sure, I'll fix this in the next version of the series. > > > Looks like you just copied the macOS errno translation code. That probably > > doesn't make sense. > > Errno values differ between Emscripten and Linux, so conversion is required > here. I've used the same mappings as macOS for now, but I'm happy to add > more conversions if needed. OK, but why have you chosen macOS errno mapping exactly? Are you testing on a macOS host machine? Are errno values of emscripten machine dependent? The errno mapping must be correct, otherwise funny things will happen on guest side if 9p2000.L client is used, as it blindly expects errno numbers sent by 9p server to be in native Linux errno number presentation. 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. /Christian
