On Mon, 20 Jun 2016 13:38:39 +1000 William ML Leslie <william.leslie....@gmail.com> wrote: > On 20 June 2016 at 06:09, Chris Vine <ch...@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
