> R7RS provides u8-ready? and char-ready? (a non-blocking check for
> more input available or EOF)
>
> ...but these custom ports do not provides hooks to implement them.
I never noticed these R7RS procedures before. How are they implemented
in the general case?
The general-case? That's the point. If there was a general case, we wouldn't need a hook for it. ;-)
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. I'm not at all versed in Windows, but google'ing the concept there suggests it's more complicated.
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.
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.