On Sat, 11 Jun 2016 19:02:09 +0200 Andy Wingo <wi...@pobox.com> wrote: > On Thu 14 Apr 2016 16:08, l...@gnu.org (Ludovic Courtès) writes: > > > Andy Wingo <wi...@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."