unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Chris Vine <chris@cvine.freeserve.co.uk>
Cc: guile-user <guile-user@gnu.org>, guile-devel <guile-devel@gnu.org>
Subject: Re: anyone define port types?
Date: Mon, 20 Jun 2016 09:34:26 +0200	[thread overview]
Message-ID: <87y460jou5.fsf@pobox.com> (raw)
In-Reply-To: <20160620074503.6d06426b@dell.homenet> (Chris Vine's message of "Mon, 20 Jun 2016 07:45:03 +0100")

On Mon 20 Jun 2016 08:45, Chris Vine <chris@cvine.freeserve.co.uk> writes:

> 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.

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).

> My approach on the other hand does not nest events from the glib main
> loop in this way.

"Nesting events" should not be a thing you have to do.

Andy



  reply	other threads:[~2016-06-20  7:34 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-28 19:04 anyone define port types? Andy Wingo
2016-03-28 23:53 ` Matt Wette
2016-04-05 14:06   ` Mark H Weaver
2016-04-05 23:55     ` Matt Wette
2016-06-11 16:50       ` Andy Wingo
2016-03-29  8:52 ` Nala Ginrut
2016-03-30  6:29 ` Panicz Maciej Godek
2016-03-30 11:18   ` Jan Nieuwenhuizen
2016-03-30 17:17     ` Panicz Maciej Godek
2016-03-30 17:53       ` Marko Rauhamaa
2016-03-30 19:02         ` Panicz Maciej Godek
2016-03-30 19:57           ` Marko Rauhamaa
2016-03-31 16:11             ` Barry Fishman
2016-03-31 19:28               ` Marko Rauhamaa
2016-03-30 19:43         ` Jan Wedekind
2016-03-30 20:07           ` Marko Rauhamaa
2016-03-30 21:01             ` Jan Wedekind
2016-03-30 22:44               ` Marko Rauhamaa
2016-03-31 20:42                 ` Jan Wedekind
2016-03-31 22:28                   ` Marko Rauhamaa
2016-06-11 16:53   ` Andy Wingo
2016-04-01 14:38 ` Ludovic Courtès
2016-06-11 16:57   ` Andy Wingo
2016-04-14 14:08 ` Ludovic Courtès
2016-06-11 17:02   ` Andy Wingo
2016-06-12  8:25     ` Chris Vine
2016-06-19  9:13       ` Andy Wingo
2016-06-19  9:55         ` Marko Rauhamaa
2016-06-19 15:27           ` Andy Wingo
2016-06-19 15:33         ` Chris Vine
2016-06-19 17:48           ` Andy Wingo
2016-06-19 20:09             ` Chris Vine
2016-06-20  3:38               ` William ML Leslie
2016-06-20  6:45                 ` Chris Vine
2016-06-20  7:34                   ` Andy Wingo [this message]
2016-06-20  9:01                     ` Chris Vine
2016-06-22 22:44                       ` Chris Vine
2016-06-23  7:36                         ` Andy Wingo
2016-06-23  8:56                           ` Andy Wingo
2016-06-23  9:24                           ` Chris Vine
2016-06-23  9:50                             ` Marko Rauhamaa
2016-06-23 10:43                             ` Andy Wingo
2016-06-23 11:49                               ` William ML Leslie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y460jou5.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=chris@cvine.freeserve.co.uk \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).