unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: wip-threads-and-fork
Date: Mon, 27 Feb 2012 10:39:11 +0100	[thread overview]
Message-ID: <87r4xg8vk0.fsf@pobox.com> (raw)
In-Reply-To: <87sjhx1cii.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sun, 26 Feb 2012 23:00:05 +0100")

Hi,

On Sun 26 Feb 2012 23:00, ludo@gnu.org (Ludovic Courtès) writes:

>> A guile built without
>> threads may fork to its heart's content.  However a guile built with
>> threads -- the default, recommended configuration -- should not call
>> primitive-fork.
>
> That’s a strong statement.

Don't shoot the messenger ;)  I tried hard to make it work, but there's
no getting around POSIX here.

> When the only threads are the main thread
> and the signal thread, everything’s alright.  For example, this works
> fine on GNU/Linux:
>
> (let ((p (primitive-fork)))
>   (case p
>     ((0)
>      (sigaction SIGINT (lambda args
>                          (format #t "kid ~a got ~a~%" (getpid) args)
>                          (exit 0)))
>      (let loop () (loop))
>      (exit 1))
>     (else
>      (sleep 2)
>      (kill p SIGINT)
>      (format #t "killed ~a~%" p)
>      (waitpid p))))
>
> It works because the signal thread is stuck in a read(2) with no lock
> taken.

"Works" ;-) It mostly works on GNU/Linux.  But not all the time!  Other
processes can send your thread signals -- indeed, one would expect that
it's for that reason that you installed a signal handler.  If the
signal-handling thread wakes up and queues an async, it could be in the
middle of allocation, hold the alloc lock, and thereby prevent the child
from allocating anything.  Or it could have the async mutex.

I really doubt that we can build a stable system on top of such shaky
guarantees.

I 

> Things that don’t work include this:
>
> (use-modules (ice-9 futures))
>
> (let* ((f (future (begin (sleep 4) (getpid))))
>        (p (primitive-fork)))
>   (case p
>     ((0)
>      (format #t "kid -> ~a~%" (touch f)))
>     (else
>      (format #t "parent -> ~a~%" (touch f))
>      (waitpid p))))
>
> Here the child waits forever because it has only one thread.

Or because some other thread has the allocation lock, or some other
lock, including even the gconv lock deep in libc, etc.

> As for popen, that’s a bug (or undocumented limitation) of (ice-9
> futures) itself, more than anything else.

Popen now works with threads.

Andy
-- 
http://wingolog.org/



  reply	other threads:[~2012-02-27  9:39 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       ` Andy Wingo [this message]
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 ` wip-threads-and-fork Ludovic Courtès

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=87r4xg8vk0.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=ludo@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).