From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: anyone define port types? Date: Sun, 12 Jun 2016 09:25:13 +0100 Message-ID: <20160612092513.3eb1c8a3@laptop.homenet> References: <87y492mnjp.fsf@pobox.com> <87pots9tag.fsf@gnu.org> <87bn37wtf2.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1465719957 27591 80.91.229.3 (12 Jun 2016 08:25:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jun 2016 08:25:57 +0000 (UTC) Cc: Ludovic =?UTF-8?B?Q291cnTDqHM=?= , guile-user , guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jun 12 10:25:45 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bC0iG-0006K8-FK for guile-devel@m.gmane.org; Sun, 12 Jun 2016 10:25:44 +0200 Original-Received: from localhost ([::1]:50200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC0iF-0002LI-L5 for guile-devel@m.gmane.org; Sun, 12 Jun 2016 04:25:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC0hv-0002L2-MX for guile-devel@gnu.org; Sun, 12 Jun 2016 04:25:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bC0hr-0006XZ-L5 for guile-devel@gnu.org; Sun, 12 Jun 2016 04:25:23 -0400 Original-Received: from host242-216-static.82-213-b.business.telecomitalia.it ([213.82.216.242]:37136 helo=laptop.homenet) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC0hr-0006WI-DK; Sun, 12 Jun 2016 04:25:19 -0400 Original-Received: from laptop.homenet (localhost [127.0.0.1]) by laptop.homenet (Postfix) with ESMTP id EA69254A55B; Sun, 12 Jun 2016 09:25:14 +0100 (BST) In-Reply-To: <87bn37wtf2.fsf@pobox.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.30; i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 213.82.216.242 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18343 gmane.lisp.guile.user:12631 Archived-At: On Sat, 11 Jun 2016 19:02:09 +0200 Andy Wingo wrote: > On Thu 14 Apr 2016 16:08, ludo@gnu.org (Ludovic Court=C3=A8s) writes: >=20 > > Andy Wingo skribis: > > =20 > >> 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=3D15463 > >> 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 :) =20 > > > > What do you conclude from this poll? :-) > > > > From what you=E2=80=99ve seen, how do you think current uses would impa= ct > > the refactoring work (and vice versa)? =20 >=20 > Sorry for the late response :) >=20 > 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. >=20 > I put in a lot of effort to the documentation; check it out: >=20 > http://www.gnu.org/software/guile/docs/master/guile.html/Input-and-Outp= ut.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."