Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Subject: RE: fork and mutexs
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: nhv AT cape DOT com
Cc: cygwin-developers AT cygwin DOT com, jason AT tishler DOT net, gsmith AT nc DOT rr DOT com
In-Reply-To: <009301c13ac7$e2303e80$a300a8c0@nhv>
References: <009301c13ac7$e2303e80$a300a8c0 AT nhv>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13 (Preview Release)
Date: 11 Sep 2001 23:56:30 +1000
Message-Id: <1000216591.7266.254.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 11 Sep 2001 13:43:21.0553 (UTC) FILETIME=[B8BF4410:01C13AC7]

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