On Mon, 20 Jun 2016 09:34:26 +0200 Andy Wingo <wi...@pobox.com> 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. Chris
