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: Mon, 20 Jun 2016 07:45:03 +0100 Message-ID: <20160620074503.6d06426b@dell.homenet> References: <87y492mnjp.fsf@pobox.com> <87pots9tag.fsf@gnu.org> <87bn37wtf2.fsf@pobox.com> <20160612092513.3eb1c8a3@laptop.homenet> <8760t5mthu.fsf@pobox.com> <20160619163327.36246706@dell.homenet> <8737o9kr3g.fsf@pobox.com> <20160619210912.48528ffa@dell.homenet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466405135 11561 80.91.229.3 (20 Jun 2016 06:45:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 06:45:35 +0000 (UTC) To: guile-user , guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 20 08:45:26 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 1bEsxX-0001UB-RB for guile-devel@m.gmane.org; Mon, 20 Jun 2016 08:45:23 +0200 Original-Received: from localhost ([::1]:41614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEsxW-0001AJ-TN for guile-devel@m.gmane.org; Mon, 20 Jun 2016 02:45:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEsxP-00019r-SW for guile-devel@gnu.org; Mon, 20 Jun 2016 02:45:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEsxJ-00007w-Uu for guile-devel@gnu.org; Mon, 20 Jun 2016 02:45:14 -0400 Original-Received: from avasout08.plus.net ([212.159.14.20]:44954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEsxJ-00007H-OD for guile-devel@gnu.org; Mon, 20 Jun 2016 02:45:09 -0400 Original-Received: from dell.homenet ([87.114.218.169]) by avasout08 with smtp id 8ul31t0063fstn301ul4mC; Mon, 20 Jun 2016 07:45:06 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=O6PEx0JW c=1 sm=1 tr=0 a=4ynVEcF4YjHkqINdvT3UIQ==:117 a=4ynVEcF4YjHkqINdvT3UIQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=pD_ry4oyNxEA:10 a=pGLkceISAAAA:8 a=Fwo3Pw8wAAAA:8 a=TZhD8YBixDMTjrImDXEA:9 a=CjuIK1q_8ugA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=sTfVWhjbJpNfc6ZWP1zY:22 Original-Received: from dell.homenet (localhost [127.0.0.1]) by dell.homenet (Postfix) with ESMTP id 7989A443386; Mon, 20 Jun 2016 07:45:03 +0100 (BST) In-Reply-To: X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.30; x86_64-unknown-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 212.159.14.20 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:18355 gmane.lisp.guile.user:12658 Archived-At: On Mon, 20 Jun 2016 13:38:39 +1000 William ML Leslie wrote: > On 20 June 2016 at 06:09, Chris Vine > wrote: > > OK I am grateful for your patience in explaining this. I need to > > think about it, but while this works where all events come from > > user-derived events, I doubt that this would work with guile-gnome > > and the glib main loop in the round, because for gtk+ to function > > the glib main loop must block within glib's own internal call to > > the poll() and not within the guile prompt, or gdk and other events > > will jam up. You would probably need to run the glib main loop in > > its own (pthread) thread, about which you have previously given > > dire warnings so far as guile as it currently stands is concerned. > > > > As I say, I really need to think more about this and look further at > > the code. I may well be missing something. > > If the event loop is external as you suggested, you could use a > different implementation of the loop that used g_io_add_watch and > returned to the glib mainloop when you're in a glib or gtk > application. Sure, but that's not really the difficulty. On further reflection on Andy's post, I think what I understand to be his approach to suspendable-ports could be made to work with a glib main loop without invoking additional pthread threads, but I think it would be barely scalable or tractable. For Andy's sake, can I give a concrete example of an entirely single threaded program? Let's say the program uses guile-gnome and is running a glib main loop, on which the program is (of necessity if using a glib main loop) blocking in g-main-loop-run, so all code is running as events in the main loop. For simplicity, let's say you have a file watch in the glib event loop which has made a non-blocking read of the first byte of a multi-byte UTF-8 character, and the suspendable-ports implementation is in use because it is a non-blocking read of a TCP socket. (It could be something different: there may be a non-blocking read request for a complete line of text which has so far only partially been satisfied, but the partially complete character is the easiest example to deal with.) The read request is therefore in read-waiter waiting for a complete UTF-8 byte sequence to arrive. On the current hypothesis, read-waiter comprises a procedure which is suspended on a prompt waiting for an event to occur in the glib main loop which will cause it to resume, comprising the file descriptor becoming ready which will satisfy the read request. But while suspended in read-waiter, this prompt would have to service any user event sources which might become ready in the glib main loop, not just the particular file descriptor in question becoming ready. These could be nested with other non-blocking reads, also in read-waiter, on other descriptors which also have a pending partial read, or with time-outs or with tasks composed with idle handlers. Any user event source which has been attached to the glib main loop which fires would have to cause all pending partial reads to go through the nested non-blocking read cycles to see if anything is available, as well as servicing the particular user event in question. It seems hardly scalable, if it would work at all. My approach on the other hand does not nest events from the glib main loop in this way. It is still possible I have missed something. The proof of all these things is in the pudding. I suppose what is needed is an attempt at a practical implementation using read-waiter: but for the moment I don't see it. Chris