Email list hosting service & mailing list manager

SRFI 181: Custom ports Arthur A. Gleckler (16 Feb 2020 08:03 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (16 Feb 2020 14:01 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (21 Feb 2020 23:24 UTC)
Re: SRFI 181: Custom ports John Cowan (22 Feb 2020 19:19 UTC)
Re: SRFI 181: Custom ports Vincent Manis (17 Feb 2020 23:04 UTC)
Re: SRFI 181: Custom ports John Cowan (18 Feb 2020 17:51 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (18 Feb 2020 18:22 UTC)
Re: SRFI 181: Custom ports John Cowan (19 Feb 2020 12:42 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (19 Feb 2020 18:11 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (19 Feb 2020 18:13 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (19 Feb 2020 18:17 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (19 Feb 2020 18:30 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (19 Feb 2020 18:51 UTC)
Re: SRFI 181: Custom ports Vincent Manis (19 Feb 2020 22:57 UTC)
Re: SRFI 181: Custom ports Jim Rees (04 Mar 2020 12:36 UTC)
u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 12:46 UTC)
Re: u8-ready? and char-ready? Jim Rees (04 Mar 2020 13:09 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 13:30 UTC)
Re: u8-ready? and char-ready? Jim Rees (04 Mar 2020 14:48 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:07 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 15:13 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:31 UTC)
Re: u8-ready? and char-ready? Marc Nieper-Wißkirchen (04 Mar 2020 15:39 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:49 UTC)
SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:08 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:13 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Marc Feeley (04 Mar 2020 16:18 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:26 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:28 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Marc Feeley (04 Mar 2020 16:46 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 17:03 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes John Cowan (04 Mar 2020 23:23 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Marc Feeley (05 Mar 2020 13:08 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes John Cowan (05 Mar 2020 20:44 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Göran Weinholt (05 Mar 2020 22:16 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes John Cowan (05 Mar 2020 22:22 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Arthur A. Gleckler (04 Mar 2020 19:26 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 15:07 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:31 UTC)
Re: u8-ready? and char-ready? Jim Rees (04 Mar 2020 15:32 UTC)
Waiting on custom ports / CL Gray Streams Lassi Kortela (04 Mar 2020 15:41 UTC)
Re: u8-ready? and char-ready? John Cowan (04 Mar 2020 17:18 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 17:26 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 14:55 UTC)
Re: SRFI 181: Custom ports Jim Rees (04 Mar 2020 19:31 UTC)
Re: SRFI 181: Custom ports John Cowan (05 Mar 2020 00:36 UTC)
Re: SRFI 181: Custom ports Jim Rees (05 Mar 2020 21:53 UTC)
Re: SRFI 181: Custom ports John Cowan (05 Mar 2020 22:08 UTC)

Re: u8-ready? and char-ready? Lassi Kortela 04 Mar 2020 13:29 UTC

> 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.