[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: full moon, vm status update
From: |
dsmich |
Subject: |
Re: full moon, vm status update |
Date: |
Thu, 16 Oct 2008 14:41:33 -0400 |
---- Andy Wingo <address@hidden> wrote:
>It seems fork + signal handling is borked with a guile compiled --with-threads
>-- and that's not
>specific to the vm branch.
And this is the very reason that Debian guile was built --without-threads.
It's just not a good idea to mix fork() with pthreads. The main issue is that
the child process has all the state of the parent, including the locked state
of all the mutexes. However, the threads that hold them no longer exist, so
deadlocks are almost inevitable. There is a pthread_atfork() call that should
allow you to make things safe before a fork() and restore them properly
afterwards. Guile *might* be able to use this to handle all the mutexes that
it creates an knows about, but what the ones a user creates in their C code, or
what some C library does?
Now, this is not much of a problem with fork()+exec(). The problem is mixing
"fork threading" (where you keep the same process image in the child) and posix
threads.
-Dale
- full moon, vm status update, Andy Wingo, 2008/10/15
- Re: full moon, vm status update, Julian Graham, 2008/10/16
- Re: full moon, vm status update, Ludovic Courtès, 2008/10/16
- Re: full moon, vm status update, Andy Wingo, 2008/10/16
- Re: full moon, vm status update, Neil Jerram, 2008/10/18
- Re: full moon, vm status update, Neil Jerram, 2008/10/27
- Re: full moon, vm status update, Andy Wingo, 2008/10/31
- Re: full moon, vm status update, Ludovic Courtès, 2008/10/31
- Re: full moon, vm status update, Andy Wingo, 2008/10/31
- Re: full moon, vm status update,
dsmich <=