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
