unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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’.

      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).