On Saturday, April 12, 2025 10:21:47 AM CEST Christian Schoenebeck wrote: > 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.
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. > > /Christian
