Re: anyone define port types?

[Chris Vine]

On Mon, 20 Jun 2016 13:38:39 +1000
William ML Leslie <address@hidden> wrote:
> On 20 June 2016 at 06:09, Chris Vine <address@hidden>
> 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