guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Potluck - thread safe event loop with await semantics


From: David Pirotte
Subject: Re: Potluck - thread safe event loop with await semantics
Date: Mon, 22 Feb 2016 17:28:04 -0300

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.
        ...


Cheers,
David

[1] https://www.gnu.org/software/guile-gnome/docs/gdk/html/Threads.html#Threads

Attachment: pgpF1VH7LrUu3.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]