Re: anyone define port types?

[Andy Wingo <wingo@pobox.com>]

Hi :)

On Sun 12 Jun 2016 10:25, Chris Vine <chris@cvine.freeserve.co.uk> writes:

>>   http://www.gnu.org/software/guile/docs/master/guile.html/Input-and-Output.html
>
> The documentation indicates that with the C ports implementation in
> guile-2.2, reads will block on non-blocking file descriptors.

Correct.

> This will stop the approach to asynchronicity used in 8sync and
> guile-a-sync (the latter of which I have written) from working
> correctly with sockets on linux operating systems, because at present
> both of these use guile's wrapper for select.

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.

As you know, the current behavior for Guile 2.0 is to throw an exception
when you get EAGAIN / EWOULDBLOCK.  If I am understanding you correctly,
your approach is to only read from a port if you have done a select() /
poll() / etc on it beforehand indicating that you can read at least one
byte.

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.

This goes not only for the explicit bufffers attached to ports and which
you can control with `setvbuf', but also implicit buffers, and it's in
this case that it's particularly pernicious: if you `read-char' on a
UTF-8 port, you might end up using local variables in the stack as a
buffer for reconstructing that codepoint.  If you throw an exception in
the middle, you discard those bytes.  Likewise for writing.

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.

> However, to cater for other asynchronous implementations of file
> watches, would it be possible to provide a configurable option either
> to retain the guile-2.0 behaviour in such cases (which is to throw a
> system-error with errno set to EAGAIN or EWOULDBLOCK), or to provide a
> non-blocking alternative whereby the read operation would, instead of
> blocking, return some special value such as an EAGAIN symbol?  Either
> would enable user code then to resume to its prompt and let other code
> execute.

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.

Andy