Re: anyone define port types?

[Chris Vine]

On Mon, 20 Jun 2016 10:01:57 +0100
Chris Vine <address@hidden> wrote:
> On Mon, 20 Jun 2016 09:34:26 +0200
> Andy Wingo <address@hidden> wrote:
> [snip]
> > I must not be communicating clearly because this is definitely not
> > what I am proposing.  The prompt doesn't service anything, and it's
> > just the one user-space thread which is suspended, and when it
> > suspends, it suspends back to the main loop which runs as usual,
> > timers and all.
> > 
> >                         prompt
> >    /------\ /------------\|/-----------\ /------------\ /----------\
> >    | main --> run-thread -|>(user code)-->  read-char -->  waiter  |
> >    | loop | |            |||           | |            | |          |
> >    \------/ \------------/|\-----------/ \------------/ \--|-------/
> >                           ^                                |
> >                            \-------------------------------/
> >    stack grows this way ->
> > 
> > The current-read-waiter aborts to a prompt.  That prompt is instated
> > when the thread is run or resumed.  When you abort to that prompt,
> > you add the FD to the poll set / main loop / *, remember the
> > delimited continuation, and return to the main loop.  When the fd
> > becomes readable or the gsource fires or whatever, you reinstate the
> > delimited continuation via a new invocation of run-thread (prompt
> > and all).  
> 
> Ah right, that is clearer, thank you.  There would indeed be a prompt
> for each user glib event source comprised in the "thread" abstraction,
> which the read-waiter (or whatever) aborts to.  It is that abstraction
> that I was missing and will need to look at.

I have stirred myself and installed guile-2.1.3.  On looking more at
the suspendable ports code it became obvious and I haven't needed to
adopt anything like ethreads with its "thread" abstraction: instead I
have kept the approach already adopted in the guile-a-sync library.
However, the consequence of using suspendable ports instead of C ports
is that the await-getline! procedure (as an example) has been reduced
to a mere 16 lines of code, mainly because it is possible to use (ice-9
rdelim)'s read-line procedure with non-blocking ports.

I have made a new repository for guile-a-sync for use with guile-2.2 and
when I am happy with the new interfaces (and assuming nothing else goes
wrong) I will put it up on github.

This is very nice.  Thanks for taking the time to go through it with me.

Chris