guile-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]