From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: wip-threads-and-fork
Date: Thu, 01 Mar 2012 20:32:39 +0100 [thread overview]
Message-ID: <87obsg6rs8.fsf@gnu.org> (raw)
In-Reply-To: 877gzx0ye0.fsf@pobox.com
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
Hi!
Andy Wingo <wingo@pobox.com> 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:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1734 bytes --]
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
[-- Attachment #3: Type: text/plain, Size: 18 bytes --]
Thanks,
Ludo’.
prev parent reply other threads:[~2012-03-01 19:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 22:10 wip-threads-and-fork Andy Wingo
2012-02-22 21:40 ` wip-threads-and-fork Andy Wingo
2012-02-23 15:05 ` wip-threads-and-fork Andy Wingo
2012-02-23 15:49 ` wip-threads-and-fork Nala Ginrut
2012-02-23 16:13 ` wip-threads-and-fork Andy Wingo
2012-02-24 3:00 ` wip-threads-and-fork Nala Ginrut
2012-02-24 10:21 ` wip-threads-and-fork Andy Wingo
2012-02-24 14:08 ` wip-threads-and-fork Nala Ginrut
2012-02-24 14:47 ` wip-threads-and-fork Andy Wingo
2012-02-24 15:25 ` wip-threads-and-fork Nala Ginrut
2012-02-26 22:03 ` wip-threads-and-fork Ludovic Courtès
2012-02-27 9:44 ` wip-threads-and-fork Andy Wingo
2012-03-01 19:40 ` wip-threads-and-fork Ludovic Courtès
2012-02-24 18:57 ` wip-threads-and-fork Andy Wingo
2012-02-25 2:21 ` wip-threads-and-fork Nala Ginrut
2012-02-25 2:30 ` wip-threads-and-fork Nala Ginrut
2012-02-25 18:01 ` wip-threads-and-fork Andy Wingo
2012-02-26 2:35 ` wip-threads-and-fork Nala Ginrut
2012-02-26 22:00 ` wip-threads-and-fork Ludovic Courtès
2012-02-27 9:39 ` wip-threads-and-fork Andy Wingo
2012-03-01 19:35 ` wip-threads-and-fork Ludovic Courtès
2012-03-03 16:32 ` wip-threads-and-fork Andy Wingo
2012-03-03 21:20 ` wip-threads-and-fork Ludovic Courtès
2012-03-04 11:38 ` wip-threads-and-fork Andy Wingo
2012-03-21 21:26 ` wip-threads-and-fork Ludovic Courtès
2012-03-22 2:48 ` wip-threads-and-fork Nala Ginrut
2012-03-23 9:40 ` wip-threads-and-fork Andy Wingo
2012-03-27 15:54 ` wip-threads-and-fork Ludovic Courtès
2012-04-06 18:30 ` wip-threads-and-fork Andy Wingo
2012-04-07 22:54 ` wip-threads-and-fork Ludovic Courtès
2013-01-17 11:41 ` wip-threads-and-fork Andy Wingo
2012-03-01 19:32 ` Ludovic Courtès [this message]
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=87obsg6rs8.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@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).