Re: Potluck - thread safe event loop with await semantics

[Chris Vine <chris@cvine.freeserve.co.uk>]

On Tue, 23 Feb 2016 03:25:52 -0300
David Pirotte <david@altosw.be> wrote:
> Hi Chris,
[snip]
> Ah. no, it segfaults here too, but as you know, this example makes a
> new <gclosure> and a new (g-idle-source-new), sets and attach the
> source ... every call: I guess the problem is none are
> freed/released, or at least not 'properly' ? I don't know.  Would an
> 'exact same' C program using pthread work fine?  Probably, but it
> would be nice to confirm.

It would and does work fine in a C program.  See also the
documentation at
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description

  "To allow multiple independent sets of sources to be handled in
   different threads, each source is associated with a GMainContext.
   A GMainContext can only be running in a single thread, but sources
   can be added to it and removed from it from other threads."

and at
https://developer.gnome.org/glib/stable/glib-Threads.html#glib-Threads.description

  "GLib itself is internally completely thread-safe (all global
   data is automatically locked), but individual data structure
   instances are not automatically locked for performance reasons. For
   example, you must coordinate accesses to the same GHashTable from
   multiple threads. The two notable exceptions from this rule are
   GMainLoop and GAsyncQueue, which are thread-safe and need no further
   application-level locking to be accessed from multiple threads."

As regards guile-gnome, I guess the problem may well be to do with the
operation of the garbage collector.  However I suspect it is caused by
too eager collection rather than too conservative collection - there is
no obvious sign of excess memory usage.  Probably the collector
sometimes frees memory still in use by the wrapper when the wrapper is
invoked in a multi-threaded context.

> In anycase, I will need Andy's help to
> debug and patch this.  Did you talked to him back then?

No.
 
[snip]
> > On a separate matter, can you fix g-io-add-watch if that has not yet
> > happened? If you try to call it, compilation errors with:
> > 
> >    ERROR: In procedure module-lookup: Unbound variable:
> > <gio-channel>  
> 
> I don't know much [almost nothing] about that part, but it fails here
> too.  I'll see what I can do but don't hold your breath,
> <gio-channel> and friends use special wrappers, so the help of Andy
> would be precious here too ...

I find <gio-channel> strange.  It is inconsistent with other naming
conventions in guile-gnome.  I wonder if it should be <g-io-channel>
and code somewhere assumes that it is?

There are a number of oddities with the wrapper.  For example, for some
reason some GTK+ modules are suppressed.  In particular, I noticed that
sound events via libcanberra don't work on guile-gnome applications.  I
did post bugs about this, and about g-io-add-watch, a number of years
ago.  The thread safety point was kind-of the final straw.

Chris