Re: anyone define port types?

[Marko Rauhamaa <marko@pacujo.net>]

Andy Wingo <wingo@pobox.com>:

> The trouble is that AFAIU there is no way to make non-blocking input
> work reliably with O_NONBLOCK file descriptors in the approach that
> Guile has always used.
>
> [...]
>
> The problem with this is not only spurious wakeups, as you note, but
> also buffering. Throwing an exception when reading in Guile 2.0 will
> discard input buffers in many cases. Likewise when writing, you won't
> be able to know how much you've written.

Guile's POSIX support provides immediate access to most OS facilities.
However, support for read(2) and write(2) seem to be missing. (Note that
Python, for example, provides both buffered, native facilities and the
low-level os.read() and os.write().)

Sure, recv! and send are there, but asynchronous I/O is more general
than socket communication.

> For suspendable ports, you don't throw an exception: you just assume
> the operation is going to work, but if you get EAGAIN / EWOULDBLOCK,
> you call the current-read-waiter / current-write-waiter and when that
> returns retry the operation. Since it operates on the lowest level of
> bytes, it's reliable. Looping handles the spurious wakeup case.

The POSIX system call simply returns whatever bytes are available at the
moment. That paradigm works perfectly. IOW, if you have buffered 10
bytes and get an EGAIN, just return those 10 bytes.

> Why not just (install-suspendable-ports!) and
>
>   (parameterize ((current-read-waiter my-read-waiter)) ...)
>
> etc? It is entirely possible with Guile 2.1.3 to build an asynchronous
> coroutine-style concurrent system in user-space using these
> primitives. See the wip-ethread branch for an example implementation.

I haven't thought it through if that callback paradigm would offer the
same degrees of freedom as the return-whatever-you-have paradigm. It
seems unnecessarily complicated, though.

I would simply violate the letter of the R?RS port semantics in Guile
and go with the POSIX semantics. It seems clear the R?RS port
specification was written without considering asynchronous communication
at all.


Marko