Re: anyone define port types?

[Andy Wingo]

Hi,

You are arguing for new I/O primitives with different semantics, and
that's fine and good :)  My goal was to add the ability to sensibly work
with non-blocking ports using Guile's existing primitives, especially
the textual ones.

This effort was started because of the ethreads work I did about four
years ago.  That required a separate implementation of buffered ports,
which is fine for a library but not good for a system.  You want to be
able to set a non-blocking port as the current input port, for example,
and you want to be able to (display x p) where p is a non-blocking port,
and you want to be able to do this both in a blocking way, because
Guile doesn't currently include any kind of user-space scheduler, but
also you want to support experiments to make a user-space scheduler.

The ethreads work from four years ago also required me to patch various
parts of Guile, like the web server, so that they could use different
primitives.  That's what I want to avoid.  I want to be able to run an
SSAX parser or a Scheme reader or writer over a non-blocking port and
have it just work.  (For SSAX it's close to working; there are a couple
of primitives that need to be reimplemented in terms of the subset of
port interfaces that suspendable ports replaces.  For Scheme
`read'/`write' the situation is more complicated.)

On Sun 19 Jun 2016 11:55, Marko Rauhamaa <address@hidden> writes:

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

A read operation is supported via `get-bytevector-some', but it's true
that `put-bytevector-some' is not implemented.

Incidentally, have you seen ljsyscall, for LuaJIT?  What a great
library.  I wish we had something like that for Guile.

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

There is complication, but it is necessary complication.  If you want to
support blocking textual operations with all of the encodings that Guile
supports over non-blocking ports, you need to be able to poll() when you
get EAGAIN; and if you also want to be able to suspend in the middle of
writing a byte sequence, many levels removed from the original write,
then you need a parameter; and if you don't know yet the entire set of
things you might want to do, that parameter better be a procedure.

In practice I find it a delight to work with this interface.  See the
memcached server and client implementations in the recently updated
wip-ethreads branch; to my eye they are lovely.

Andy