Re: Potluck - thread safe event loop with await semantics

[Chris Vine]

On Mon, 22 Feb 2016 17:28:04 -0300
David Pirotte <address@hidden> wrote:
> Hello Chris,
> 
> Nice work, tell us when uploaded as a git repo, I'd like to look at
> it when I have some time.
> 
> > This is an example of how you might use a-sync with guile-gnome:
> > ...  
> 
> > However, it is more useful with guile-gnome's GTK+ callbacks, or
> > with glib file watches or timeouts, because although the glib main
> > loop is thread safe, the guile-gnome wrapper for it is not, and I
> > have had problems with worker threads posting with g-idle-add.  
> 
> This is not correct:  Guile-Gnome [correctly] wraps glib, gdk and gtk
> and as such, provides the exact same functionality you'd have writing
> your app in C. Guile-Gnome does _not_introduce thread unsafety, it is
> neither more neither less 'powerful' wrt this thread
> problem/discussion, it just can't do 'better' then glib, gdk and gtk
> themselves.  Here is a more accurate def of the thread safety
> characteristic of these 'modules' [1]:
> 
>       ...
>       GLib is completely thread safe (all global data is
> automatically locked), but individual data structure instances are
> not automatically locked for performance reasons. So e.g. you must
> coordinate accesses to the same <g-hash-table> from multiple threads. 
> 
> ->    GTK+ is "thread aware" but not thread safe; it provides a
> global lock controlled by gdk-threads-enter/gdk-threads-leave which
> protects all use of GTK+. That is, only one thread can use GTK+ at
> any given time.
> 
>       You must call g-thread-init and gdk-threads-init before
> executing any other GTK+ or GDK functions in a threaded GTK+ program.
> 
>       Idles, timeouts, and input functions are executed outside of
> the main GTK+ lock. So, if you need to call GTK+ inside of such a
> callback, you must surround the callback with a
> gdk-threads-enter/gdk-threads-leave pair. (However, signals are still
> executed within the main GTK+ lock.)
> 
> ->    In particular, this means, if you are writing widgets that
> might be used in threaded programs, you must surround timeouts and
> idle functions in this matter.
> 
>       As always, you must also surround any calls to GTK+ not made
> within a signal handler with a gdk-threads-enter/gdk-threads-leave
> pair. ...

David,

When I tested guile-gnome a few years ago I could reliably get
g-idle-add to crash when calling it from a worker thread.  If that is
no longer the case I am pleased to hear it.  However, the little test
program at the end[1], which prints to the screen every 1/10th of a
second, will also segfault for me if I run it in a terminal for
somewhere between 1 and 5 minutes.  It seems to crash more readily if
it is in a terminal not on the current virtual desktop, but will in the
end crash even when it is.

As it happens, I am familiar with GTK+/glib thread safety. I have
written a library which depends on it.  g_idle_add(), and the other
glib main loop functions, are and always have been completely thread
safe.  As it happens, g-thread-init isn't wrapped, but there is no need
to call g_thread_init() anyway since glib >= 2.32.  This is not to be
confused with invocation of the GDK global lock, which has nothing to
do with glib but is a GDK/GTK+ matter, and is now deprecated as of
GDK3/GTK+3 and has only ever worked on X (it has never worked on
windows and won't work on Wayland).  The correct way to send events
from worker threads to GDK nowadays is using g_idle_add() and cognates. 

If you are writing a library you might still need to use the deprecated
gdk_threads_add_idle() instead of g_idle_add() if you want to cater for
user programs which still use the deprecated GDK global lock, but not
otherwise.

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>

It's been like that for a number of years and when I last tested did
not function in guile-gnome-platform-2.16.3.

It is off topic, but what guile-gnome really needs is a wrapper for
gobject-introspection.

Chris

[1]  Test program:
-------------------------------
#! /usr/bin/guile-gnome-2 \
-e main -s
!#

(use-modules (gnome glib))

(define main-loop (g-main-loop-new #f #f))

(call-with-new-thread
 (lambda ()
   (let loop ()
     (g-idle-add (lambda () (display "running ") #f))
     (usleep 100000)
     (loop))))
 
(display "Starting main loop\n")

(g-main-loop-run main-loop)
----------------------------------