From: David Pirotte <david@altosw.be>
To: Chris Vine <chris@cvine.freeserve.co.uk>
Cc: guile-user@gnu.org
Subject: Re: Potluck - thread safe event loop with await semantics
Date: Mon, 22 Feb 2016 17:28:04 -0300 [thread overview]
Message-ID: <20160222172804.6d40b0c3@capac> (raw)
In-Reply-To: <20160222174056.2091d806@dell.homenet>
[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-02-22 20:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 21:45 Potluck - thread safe event loop with await semantics Chris Vine
2016-02-22 12:01 ` Ludovic Courtès
2016-02-22 16:36 ` Marko Rauhamaa
2016-02-22 17:40 ` Chris Vine
2016-02-22 17:53 ` Thompson, David
2016-02-22 18:12 ` Chris Vine
2016-02-22 19:54 ` Christopher Allan Webber
2016-02-22 20:28 ` David Pirotte [this message]
2016-02-23 0:31 ` Chris Vine
2016-02-23 1:30 ` Chris Vine
2016-02-23 19:55 ` David Pirotte
2016-02-23 6:25 ` David Pirotte
2016-02-23 12:09 ` Chris Vine
2016-02-23 16:49 ` Chris Vine
2016-02-25 23:22 ` David Pirotte
2016-02-23 4:58 ` Chris Vine
2016-03-01 20:39 ` Amirouche Boubekki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160222172804.6d40b0c3@capac \
--to=david@altosw.be \
--cc=chris@cvine.freeserve.co.uk \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).