[Top][All Lists]

[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 
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 
provides the exact same functionality you'd have writing your app in C. 
does _not_introduce thread unsafety, it is neither more neither less 'powerful' 
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 
        GTK+ or GDK functions in a threaded GTK+ program.

        Idles, timeouts, and input functions are executed outside of the main 
        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

        As always, you must also surround any calls to GTK+ not made within a 
        handler with a gdk-threads-enter/gdk-threads-leave pair.



Attachment: pgpF1VH7LrUu3.pgp
Description: OpenPGP digital signature

reply via email to

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