[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-threads-and-fork
From: |
Ludovic Courtès |
Subject: |
Re: wip-threads-and-fork |
Date: |
Wed, 21 Mar 2012 22:26:12 +0100 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) |
Hello!
(With delay...)
Andy Wingo <address@hidden> skribis:
> I would have preferred this, but I came to the conclusion that this
> approach is not sound.
Without exposing ‘pthread_atfork’, how would you suggest making user
code “fork-safe”? A use case would be reviving the futures thread pool
after ‘fork’.
> Did you see that I merged the atfork bits into master?
> (wip-threads-and-fork also had some CLOEXEC bits that needed more
> baking). They worked... sorta. They had a few problems:
>
> 1) It's impossible to work around the lack of atfork() in libraries
> that you depend on.
>
> For example, wip-threads-and-fork called fork() within the GC alloc
> lock, to get around the lack of a pthread_atfork() in libgc. But
> then I submitted a patch to make libgc do this itself:
>
>
> http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/4940
>
> It's pretty difficult to tell which version of libgc you would
> have. There is no workaround that is sufficient.
Indeed, good point.
> 2) POSIX explicitly disclaims the result of calling non-signal-safe
> primitives after a fork() of a multithreaded program.
Right, though reality seems to be more pleasant than POSIX. ;-)
> 3) Nobody cares about these bugs. See e.g. the lack of response at
> http://sourceware.org/bugzilla/show_bug.cgi?id=13725. Even Bruno
> didn't reply to the Cc. See point (2).
>
> 4) The atfork mechanism imposes a total ordering on locks. This is
> possible for static locks, but difficult for locks on collectable
> Scheme objects.
>
> 5) Relatedly, just to be able to lock all weak tables at a fork, we
> had to create a new weak table-of-tables and add the tables to it.
> This is needless complication and overhead.
>
> 6) scm_c_atfork() is a broken interface. Because it hangs its hooks
> off of one pthread_atfork() invocation, it can cause newer locks to
> insert themselves in the wrong position relative to
> pthread_atfork() calls made between when Guile installed the
> scm_c_atfork handler, and the call to scm_c_atfork.
>
> There can be only one pthread_atfork() list, in a correct program.
OK, thanks for the nice summary. Indeed, this is a complex story.
> In the end I reverted those patches because they were just complication
> that didn't solve any fundamental problems.
OK.
> I came to the opinion, having run a threaded, forking program, that we
> would be much better off if we provided good abstractions to spawn
> processes, but that expecting fork() to work in a multithreaded program
> is not realistic.
Yes, things like ‘open-process’ make sense.
What about adding a big fat warning in the doc about use of
‘primitive-fork’ in a multi-threaded program?
> Still, there is one other thing that perhaps we could do to shut down
> the signal handling thread around a fork(). Dunno, perhaps it is worth
> looking into.
What would be the expected benefit?
Thanks,
Ludo’.
- Re: wip-threads-and-fork, Ludovic Courtès, 2012/03/01
- Re: wip-threads-and-fork, Ludovic Courtès, 2012/03/01
- Re: wip-threads-and-fork, Andy Wingo, 2012/03/03
- Re: wip-threads-and-fork, Ludovic Courtès, 2012/03/03
- Re: wip-threads-and-fork, Andy Wingo, 2012/03/04
- Re: wip-threads-and-fork,
Ludovic Courtès <=
- Re: wip-threads-and-fork, Nala Ginrut, 2012/03/21
- Re: wip-threads-and-fork, Andy Wingo, 2012/03/23
- Re: wip-threads-and-fork, Ludovic Courtès, 2012/03/27
Re: wip-threads-and-fork, Ludovic Courtès, 2012/03/01