> The general-case?   That's the point.  If there was a general case, we
> wouldn't need a hook for it. ;-)

The specific cases are quite complicated; the general case might be
prohibitively complicated.

>     On Unix, blocking vs non-blocking mode is a property of a file
>     object the kernel.
>
> The question of whether input is available does not depend on this property.
>
>     Is select()/poll() usable for a u8-ready? check that doesn't depend on
>     the blocking mode of the underlying file object?
>
> For POSIX-style file descriptors, yes -- that's how to poll for
> available input.

Thanks. That answers my question.

> I'm not at all versed in Windows, but google'ing the
> concept there suggests it's more complicated.

Me neither, but I got the impression that WaitForSingleObject() and
WaitForMultipleObjects() are the usual fare over there.

<https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject>

<https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects>

> One could imagine other styles of custom input where ready? could return
> #f  -- computed data being generated on another thread, a custom 'pipe'
> associated with a custom output port, etc.

These are good examples.

> But even if we assumed u8-ready? was only interesting for
> file-descriptor-based ports, we would then still need a hook to get at
> that file descriptor, but I don't think we want that since not every
> platform has file-descriptors.

For file-descriptor-based ports we could presumable re-use the R7RS
u8-ready? procedure. But it feels like the kind of thing that has pitfalls.

More generally, I'm not convinced that it's the best idea to have
standard procedures to test for a single port. It's often useful to wait
for multiple things at once, and waiting for only one thing can be done
as a special case of that.

In the case of custom ports, how do you wait for more than one custom
port at a time? Do you loop around the list of ports, calling their
ready? procedures repeatedly until one answers in the affirmative?

- If you call each ready? procedure in the same thread, and one of them
is slow, other ports that might be ready faster will stall.

- If you call each ready? procedure in its own thread concurrently, that
has all the usual issues that threads have.

- If you call the ready? procedures concurrently, you have to wait for
all of them to finish, and keep state about which ones are ready. We
have to assume that a ready? procedure can be side-effecting, hence the
state-saving.

- If we provide only a single-port ready? check as standard, does that
mean users should roll their own multi-port checks, and how?

It seems like a lot of complexity for use cases that are quite niche.