From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Signal thread Date: Tue, 28 Jun 2011 18:46:42 +0200 Message-ID: <87tyb9oqdp.fsf@inria.fr> References: <87boxjuuwh.fsf@gnu.org> <87pqlzt35m.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1309279944 15842 80.91.229.12 (28 Jun 2011 16:52:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2011 16:52:24 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jun 28 18:52:20 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QbbWN-0005Vh-8e for guile-devel@m.gmane.org; Tue, 28 Jun 2011 18:52:19 +0200 Original-Received: from localhost ([::1]:33956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbbWM-0002m2-Fl for guile-devel@m.gmane.org; Tue, 28 Jun 2011 12:52:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbbR6-000116-QV for guile-devel@gnu.org; Tue, 28 Jun 2011 12:46:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbbR4-0002iz-HD for guile-devel@gnu.org; Tue, 28 Jun 2011 12:46:52 -0400 Original-Received: from solo.fdn.fr ([80.67.169.19]:60465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbbR4-0002iF-3D for guile-devel@gnu.org; Tue, 28 Jun 2011 12:46:50 -0400 Original-Received: from nixey (reverse-83.fdn.fr [80.67.176.83]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lcourtes) by smtp.fdn.fr (Postfix) with ESMTPSA id 04CE444235; Tue, 28 Jun 2011 18:46:46 +0200 (CEST) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 10 Messidor an 219 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 80.67.169.19 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12595 Archived-At: Hello fellow Guiler of the Guild! Andy Wingo skribis: > Hello guild-comrade Court=C3=A8s! > > On Mon 27 Jun 2011 18:00, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> "Andy Wingo" skribis: >> >>> commit 3b971a59b55586a236c3621a55515d9272ee5c80 >>> Author: Andy Wingo >>> Date: Thu Jun 23 11:24:16 2011 +0200 >>> >>> don't spawn the signal delivery thread in a thread-exit handler >>>=20=20=20=20=20 >>> * libguile/threads.c (do_thread_exit): Remove needless spawn of the >>> signal delivery thread. >> >> Out of curiosity, what=E2=80=99s the rationale? Should it be done in st= able-2.0 >> as well? > > Out of curiosity, I looked :) The commit that added the spawning code > was 2e77f7202b11ad0003831fcff94ec7db80cca015 from you, which > unfortunately has no log. After a moment of shame, I looked at libguile/ChangeLog-2008 and found evidence that I=E2=80=99m only confederate at worst: 2007-10-20 Julian Graham Add support for thread cancellation and user-defined thread cleanup handlers. Small rework by Ludovic Court=C3=A8s. * null-threads.h (scm_i_pthread_cancel, scm_i_pthread_cleanup_push, scm_i_pthread_cleanup_pop): New. * pthread-threads.h (scm_i_pthread_cancel, scm_i_pthread_cleanup_push, scm_i_pthread_cleanup_pop): New. * scmsigs.c (scm_i_signal_delivery_thread, signal_delivery_thread_mutex): New. (signal_delivery_thread): Leave when `read_without_guile ()' returns zero. (start_signal_delivery_thread): Acquire SIGNAL_DELIVERY_THREAD before spawning the thread. Initialize SCM_I_SIGNAL_DELIVERY_THREAD. (ensure_signal_delivery_thread): Renamed to... (scm_i_ensure_signal_delivery_thread): this. (scm_i_close_signal_pipe): New. * scmsigs.h: Updated. * threads.c (thread_mark): Mark `t->cleanup_handler'. (guilify_self_1): Initialize `t->cleanup_handler' and `t->canceled'. (do_thread_exit): Invoke `t->cleanup_handler'. (on_thread_exit): Call `scm_i_ensure_signal_delivery_thread ()'. Call `scm_i_close_signal_pipe ()' when the next-to-last thread vanishes. (scm_leave_guile_cleanup): New. (scm_i_with_guile_and_parent): Use `scm_i_pthread_cleanup_push ()' and `scm_leave_guile_cleanup ()' to leave guile mode, rather than call `scm_leave_guile ()' after FUNC. (scm_cancel_thread, scm_set_thread_cleanup_x, scm_threads_cleanup): New. (scm_all_threads): Remove SCM_I_SIGNAL_DELIVERY_THREAD from the returned list. * threads.h (scm_i_thread)[cleanup_handler, canceled]: New fields. Add declarations of new functions. Pffew. The explanation appears to be at : * If the signal delivery thread got launched a little bit too late, it could be holding its startup mutex and then attempt to grab the thread_admin_mutex, which could be held by a thread that was in the process of being canceled and which was trying to obtain the signal delivery thread's startup mutex. I've resolved this by forcing the signal delivery thread to start (if it hasn't already) during thread cancellation of any thread. At first sight it still holds. I checked on =E2=80=98stable-2.0=E2=80=99 by applying 3b971a59b55586a236c3621a55515d9272ee5c80 and then running threads.test under Helgrind, which didn=E2=80=99t report any lock order issue. It could= mean that I was lucky, though. > Actually, let's take this opportunity to have a moment of silence for > Arch. And the terrible tla-cvs-sync! >> As a side note, why does this area have to change so often? :-) > > I understand the frustration :) Threads are hard, signals are hard, GC > and threads and signals is hard. But I do hope it's getting better. We have too few tests for the tricky corner cases, but OTOH they are difficult to write. The number of simpler thread-related tests has increased though, which probably means we caught a few bugs already, so there=E2=80=99s hope! ;-) Thanks, Ludo=E2=80=99.