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: wip-threads-and-fork Date: Thu, 01 Mar 2012 20:32:39 +0100 Message-ID: <87obsg6rs8.fsf@gnu.org> References: <877gzx0ye0.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: dough.gmane.org 1330630417 24293 80.91.229.3 (1 Mar 2012 19:33:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2012 19:33:37 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 01 20:33:36 2012 Return-path: Envelope-to: guile-devel@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 1S3Bkt-000872-LW for guile-devel@m.gmane.org; Thu, 01 Mar 2012 20:33:35 +0100 Original-Received: from localhost ([::1]:58494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Bks-0007fb-VW for guile-devel@m.gmane.org; Thu, 01 Mar 2012 14:33:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3BkX-0007ck-I9 for guile-devel@gnu.org; Thu, 01 Mar 2012 14:33:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3BkD-0003Ji-68 for guile-devel@gnu.org; Thu, 01 Mar 2012 14:33:13 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3BkC-0003JE-RP for guile-devel@gnu.org; Thu, 01 Mar 2012 14:32:53 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S3BkA-0007Yt-Ag for guile-devel@gnu.org; Thu, 01 Mar 2012 20:32:50 +0100 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Mar 2012 20:32:50 +0100 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Mar 2012 20:32:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 88 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 12 =?iso-8859-1?Q?Vent=F4se?= an 220 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.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) Cancel-Lock: sha1:FOKdeK6nXfU9+l6OmvsZQmsoM2c= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:13967 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi! Andy Wingo skribis: > The solution is, besides just avoiding fork() and threads, to take locks > on all interesting data structures when you fork(). Fortunately there > are not too many, and most locks are not nested, so it seems to be a > doable thing. In wip-threads-and-fork, I added a scm_c_atfork interface > to define functions to call before and after a fork. I finally looked in more details at the branch. In particular, this part looks great): 7329a5db * use scm_c_atfork_lock_static_mutex for guile's static mutexen 585eb4f7 * add scm_c_atfork_lock_static_mutex 9f6ac5d7 * add atfork interface What about merging these in stable-2.0? (With additional comments–e.g., to describe ‘scm_c_atfork’–and correct indentation, and without the weak-set part of 9f6ac5d7.) However, these patches don’t seem to handle the specific issue that ‘signal_delivery_thread’ could be holding the allocation lock when ‘fork’ runs. What about doing something along these lines: --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/libguile/scmsigs.c b/libguile/scmsigs.c index 86fce0f..e062f24 100644 --- a/libguile/scmsigs.c +++ b/libguile/scmsigs.c @@ -1,4 +1,4 @@ -/* Copyright (C) 1995,1996,1997,1998,1999,2000,2001, 2002, 2004, 2006, 2007, 2008, 2009, 2011 Free Software Foundation, Inc. +/* Copyright (C) 1995,1996,1997,1998,1999,2000,2001, 2002, 2004, 2006, 2007, 2008, 2009, 2011, 2012 Free Software Foundation, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public License @@ -183,6 +183,12 @@ read_signal_pipe_data (void * data) return NULL; } +/* Lock to protect async queuing. Since `system-async-mark' conses, and + thus acquires the GC lock, this lock ensures that the signal thread + doesn't call `system-async-mark' in the middle of a `fork'. */ +static scm_i_pthread_mutex_t signal_async_mutex = + SCM_I_PTHREAD_MUTEX_INITIALIZER; + static SCM signal_delivery_thread (void *data) { @@ -212,7 +218,11 @@ signal_delivery_thread (void *data) h = SCM_SIMPLE_VECTOR_REF (signal_handler_asyncs, sig); t = SCM_SIMPLE_VECTOR_REF (signal_handler_threads, sig); if (scm_is_true (h)) + { + scm_i_pthread_mutex_lock (&signal_async_mutex); scm_system_async_mark_for_thread (h, t); + scm_i_pthread_mutex_unlock (&signal_async_mutex); + } } else if (sigdata.n == 0) break; /* the signal pipe was closed. */ @@ -713,6 +723,8 @@ scm_init_scmsigs () signal_handler_asyncs = scm_c_make_vector (NSIG, SCM_BOOL_F); signal_handler_threads = scm_c_make_vector (NSIG, SCM_BOOL_F); + scm_c_atfork_lock_static_mutex (&signal_async_mutex); + for (i = 0; i < NSIG; i++) { #ifdef HAVE_SIGACTION --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks, Ludo’. --=-=-=--