From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: Potluck - thread safe event loop with await semantics Date: Tue, 23 Feb 2016 00:31:21 +0000 Message-ID: <20160223003121.4ae217f1@dell.homenet> References: <20160216214512.42e6fd39@bother.homenet> <878u2dosxu.fsf@gnu.org> <20160222174056.2091d806@dell.homenet> <20160222172804.6d40b0c3@capac> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1456187506 26736 80.91.229.3 (23 Feb 2016 00:31:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Feb 2016 00:31:46 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 23 01:31:38 2016 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aY0t8-0006Po-8M for guile-user@m.gmane.org; Tue, 23 Feb 2016 01:31:38 +0100 Original-Received: from localhost ([::1]:52839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY0t7-00081Z-OR for guile-user@m.gmane.org; Mon, 22 Feb 2016 19:31:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY0sy-00081F-WF for guile-user@gnu.org; Mon, 22 Feb 2016 19:31:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY0sv-00086k-OV for guile-user@gnu.org; Mon, 22 Feb 2016 19:31:28 -0500 Original-Received: from avasout08.plus.net ([212.159.14.20]:33237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY0sv-00086S-FQ for guile-user@gnu.org; Mon, 22 Feb 2016 19:31:25 -0500 Original-Received: from dell.homenet ([87.115.102.251]) by avasout08 with smtp id McXM1s0025RSpqF01cXN52; Tue, 23 Feb 2016 00:31:22 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=O6PEx0JW c=1 sm=1 tr=0 a=LKYHlaG36XqnqgCEqUWx/g==:117 a=LKYHlaG36XqnqgCEqUWx/g==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=jFJIQSaiL_oA:10 a=osKY3i7BZrKFH_LkqLQA:9 a=aIlEop3rlXpTJT4d:21 a=QW0vJnU_ZzpsFHc5:21 a=CjuIK1q_8ugA:10 Original-Received: from dell.homenet (localhost [127.0.0.1]) by dell.homenet (Postfix) with ESMTP id 66936443A39 for ; Tue, 23 Feb 2016 00:31:21 +0000 (GMT) In-Reply-To: <20160222172804.6d40b0c3@capac> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-unknown-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 212.159.14.20 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12429 Archived-At: On Mon, 22 Feb 2016 17:28:04 -0300 David Pirotte 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 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: 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) ----------------------------------