From: Chris Vine <chris@cvine.freeserve.co.uk>
To: guile-user <guile-user@gnu.org>, guile-devel <guile-devel@gnu.org>
Subject: Re: anyone define port types?
Date: Mon, 20 Jun 2016 07:45:03 +0100 [thread overview]
Message-ID: <20160620074503.6d06426b@dell.homenet> (raw)
In-Reply-To: <CAHgd1hF+eArKGNnh5yugvUpWSpiyu3=qidg=Hj9Y-J9Cj3M=8g@mail.gmail.com>
On Mon, 20 Jun 2016 13:38:39 +1000
William ML Leslie <william.leslie.ttg@gmail.com> wrote:
> On 20 June 2016 at 06:09, Chris Vine <chris@cvine.freeserve.co.uk>
> 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
next prev parent reply other threads:[~2016-06-20 6:45 UTC|newest]
Thread overview: 44+ 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 7:58 ` tomas
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 [this message]
2016-06-20 7:34 ` Andy Wingo
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=20160620074503.6d06426b@dell.homenet \
--to=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).