Hello, Thomas Munro, le mar. 18 nov. 2025 18:32:38 +1300, a ecrit: > On Tue, Nov 18, 2025 at 12:31 PM Samuel Thibault > > > Possibly too private/undocumented anyway, > > > > It's not really documented much, but it's completely public. One > > can include <hurd/io_request.h> and call e.g. io_read_request(port, > > reply_port, offset, amount). One then has to run a msgserver loop on the > > reply_port to get the reply messages. An example can be seen in the hurd > > source in trans/streamio.c, for e.g. device_open_request() calls. > > OK, to continue the thought experiment... someone could invent write > io_method=hurd, and it'd have to be more efficient than handing the > work off to I/O worker processes (what you get with the default > io_method=worker), since the worker process clearly has to do exactly > the same thing internally in a synchronous wrapper function anyway, > just with extra steps to reach it.
Yes, you'd avoid having to block a whole thread for just one request, and instead just queue requests, and process replies. > They'd need to be able to consume from each other's reply port > occasionally, but I assume that's possible with an exclusive lock and > a temporary transfer of receive rights. Yes, you can transfer ports between processes. > I doubt it'd be much good without a readv/writev operations, though. > It looks they aren't in io_request.defs yet? They have not been defined so far indeed. > Does that also imply that preadv() has to loop over the vectors > sending tons of messages and waiting for replies? Currently glibc's preadv performs copies. > (And then to get more and more pie-in-the-sky: (1) O_DIRECT is highly > desirable for zero-copy DMA to/from a user space buffer pool, We don't currently have that defined. > (2) starting more than one I/O with a single context switch and likewise > for consuming replies, That would be possible by introducing in gnumach a multi-message variant of the mach_msg() system call. > (3) registering/locking memory pages and descriptors with a port so > they don't have to be pinned/unpinned by the I/O subsystem all the > time. That could be introduced too indeed. > And then, if Hurd works the way I think it might, (4) to avoid chains > of pipe-like scheduling overheads when starting a direct I/O and > maybe also some already-cached buffered I/O, you'd ideally want ports > to have a "fast" send path that behaves like the old Spring/Solaris > doors, where the caller's thread would yield directly to a thread in > the receiving server, That was proposed/experimented, called migrating threads: https://www.gnu.org/software/hurd/open_issues/mach_migrating_threads Samuel
