Open windelbouwman opened 4 years ago
libuv seems to have a different execution model, namely a event queue. Events are executed after each other, and cannot be context switched; the execution of one event must finished, before another one is executed. A Zth-way of doing IO would be to do a blocking call (which only blocks the current fiber, not the worker thread). If concurrent IO is required, just start multiple fibers and block each of them on their IO.
The cross-platform API is interesting though. A naive implementation to integrate libuv would be to create a fiber that calls uv_run(..., UV_RUN_NOWAIT) with zth::yield() in a loop. In this way, all events are handled in the same worker thread and same fiber. If one would yield within an event handler, it would yield to another fiber, but would still block libuv's event loop. However, it would be possible to create a fiber from within an event handler, if longer processing would be required.
Is this the kind of integration you envisioned?
Is this the kind of integration you envisioned?
I'm not sure what I had in mind :). Just the fact that libuv seems to be a cross platform event based IO library, would make it an interesting target for zth. Assuming zth can be configured to run on multiple backends. I encountered libuv in the wasm3 project, where it is one of the 4 different backends. The other IO backends are manually implemented.
One idea for zth might be to be able to select what backend you want to use for actual IO. On PC platform, you would choose libuv, on embedded you would choose another IO backend.
The way zth would use libuv would be that zth would invoke the uv_run or uv_poll method (if it exists) and then subsequently the triggered events would enable zth fibers for scheduling. Something like that :+1:
A cool addition might be support for libuv using a configure option.
Libuv library: https://github.com/libuv/libuv
Benefits of using libuv: expose all of the libuv API in a cross platform way, so you have sockets and filesystem IO asynchronously.