Re: anyone define port types?

[Chris Vine <chris@cvine.freeserve.co.uk>]

On Sat, 11 Jun 2016 19:02:09 +0200
Andy Wingo <wingo@pobox.com> wrote:
> On Thu 14 Apr 2016 16:08, ludo@gnu.org (Ludovic Courtès) writes:
> 
> > Andy Wingo <wingo@pobox.com> skribis:
> >  
> >> I am working on improving our port implementation to take
> >> advantage of the opportunity to break ABI in 2.2.  I am wondering
> >> how much I can break C API as well -- there are some changes that
> >> would allow better user-space threading
> >> (e.g.
> >> http://thread.gmane.org/gmane.lisp.guile.devel/14158/focus=15463
> >> or Chris Webber's 8sync).  But those changes would require some
> >> incompatible changes to the C API related to port internals.  This
> >> API is pretty much only used when implementing port types.  So, I
> >> would like to collect a list of people that implement their own
> >> ports :) I know Guile-GNOME does it for GNOME-VFS, though
> >> GNOME-VFS is super-old at this point...  Anyway.  Looking forward
> >> to your links :)  
> >
> > What do you conclude from this poll?  :-)
> >
> > From what you’ve seen, how do you think current uses would impact
> > the refactoring work (and vice versa)?  
> 
> Sorry for the late response :)
> 
> My conclusion is that we should not change anything about the Scheme
> interface, but that with close communication with C port hackers, we
> can feel OK about changing the C interface to make it both more
> simple and more expressive.  Since libguile is parallel-installable
> and you have to select the version of your Guile when you build your
> project, of course people will be able to update / upgrade when they
> choose to.
> 
> I put in a lot of effort to the documentation; check it out:
> 
>   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.

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.  This arises because with
linux you can get spurious wake-ups with select() or poll() on sockets,
whereby a read on a file descriptor for a socket can block even though
the descriptor is reported by select() or poll() as ready for
reading[1].

Presumably suspendable ports will use some method to work around
unwanted blocking arising from spurious select()/poll() wake-ups.
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.

Chris

[1] The man page for select states "Under Linux, select() may report a
socket file descriptor as 'ready for reading', while nevertheless a
subsequent read blocks.  This could for example happen when data has
arrived but upon examination has wrong checksum and is discarded.  There
may be other circumstances in which a file descriptor is spuriously
reported as ready.  Thus it may be safer to use O_NONBLOCK on sockets
that should not block."