On Tue, 23 Feb 2016 03:25:52 -0300 David Pirotte <[email protected]> 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
