Date: Wed, 19 Nov 2025 23:45:07 +0100
From: Samuel Thibault <samuel.thibault@gnu.org>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Banck <mbanck@gmx.net>, Alexander Lakhin <exclusion@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: GNU/Hurd portability patches
Message-ID: <aR5Ic421-i4V1SPb@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@gnu.org>,
	Thomas Munro <thomas.munro@gmail.com>,
	Michael Banck <mbanck@gmx.net>,
	Alexander Lakhin <exclusion@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
References: <68d629f2.050a0220.3685b9.5ce2@mx.google.com>
 <CA+hUKGJE_moUF74c97GkoP6RaknRMoeFOednXe2FyXnS_bOTFQ@mail.gmail.com>
 <e2bf13d1-f152-4d1d-acbe-a8c4c41611fd@gmail.com>
 <CA+hUKGKo6rToAxyObEnOnOiT3QEJuJFVkVNqikw0wVFHag=3Fg@mail.gmail.com>
 <fa85e679-9d13-43ae-8882-3f50c709f446@gmail.com>
 <CA+hUKGLvrBt9bkjiHb8VOTGOsKfL6W0ik1+h0M1E5TSy1=QmJg@mail.gmail.com>
 <69125dd5.170a0220.d19df.23dcSMTPIN_ADDED_BROKEN@mx.google.com>
 <CA+hUKGKAUa7ybQ9=6ap2uh-TmHtH8wFL-DTeeh-swprg+Rf=+w@mail.gmail.com>
 <aRuwX88mdP8tfuvi@end>
 <CA+hUKGKD0EOviHPG_W5gBZ+xiRFktvn=tBebrSBf8oQDecKnwA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+hUKGKD0EOviHPG_W5gBZ+xiRFktvn=tBebrSBf8oQDecKnwA@mail.gmail.com>
Organization: I am not organized
Archived-At: <https://www.postgresql.org/message-id/aR5Ic421-i4V1SPb%40end>
Precedence: bulk

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