This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: fork and mutexs


On Tue, 2001-09-11 at 23:44, Norman Vine wrote:
> Robert Collins writes:
> >
> >I've just checked in a fix for mutexs, condition variables and
> >semaphores in forked process's. I'm amazed we haven't had more
> >complaints about this not working before now...
> >
> >Jason, could you please try your python again. The fix makes the test
> >case I created (remember the Pthread_test suite I sent you a while back)
> >pass, but there may be more daemons lurk()ing.
> 
> Robert
> 
> This fails sporadically < sometimes passes, but usually fails  > 
> the python forking regression test with the following error message
> 
> python.exe *** Forked() while a mutex has condition variables waiting on it

Ok, 
1) I had a bug in the inital commit. Can you CVS update again please. 
2) This is a tricky situation to manage... consider this:

we have 3 threads,
thread 1 has is waiting on cond1--mutex1
thread 2 has the mutex mutex1
thread 3 forks()

the new process has one thread
cond1 is marked as having 1 waiting thread - wrong
mutex1 is marked as not being own by anyone, but has 1 condwait waiting
for it - wrong

Now, the IEEE 1003.1 spec is pretty unhelpful I can tell you. It's
comment paraphrased is "After a fork the child contains the address
space of the parent, and items such as mutexs may be in an inconsistent
state. Therefore the child can only call async signal safe functions
until it calls one of the exec() family of functions".

In other words, fork() is allowed to break mutexs etc, child
applications had d**m well better exec quickly OR use pthread_atfork()
to syncronise the parents threads before forking.

I put that sanity check in there because I suspected we'd find many
broken programs, and I'm not happy to see that I was right. It's easy
enough to make cygwin not care - we just zero out the relevant fields
and make the mutex's and cond variables act as though they had just had
mutex_init called on them. After all, we already lose the mutex owner
data.
 
> Let me know what else I can do to help.

If you're willing, I can send you a patch to make cygwin ignore that
error with no in-cygwin side effects.. or you can fix Python :].

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]