This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: fork and mutexs
- To: Robert Collins <robert dot collins at itdomain dot com dot au>
- Subject: Re: fork and mutexs
- From: Jason Tishler <jason at tishler dot net>
- Date: Tue, 11 Sep 2001 12:38:01 -0400
- Cc: nhv at cape dot com, cygwin-developers at cygwin dot com, gsmith at nc dot rr dot com
Rob,
On Tue, Sep 11, 2001 at 11:56:30PM +1000, Robert Collins wrote:
> On Tue, 2001-09-11 at 23:44, Norman Vine wrote:
> 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 :].
With the attach "ugly" patch, Python passes all regression tests (except
for the unrelated test_strftime) again. Specifically, test_fork1 passes
with the occasional warnings:
test_fork1
*** Forked() while a mutex has condition variables waiting on it.
Report to cygwin@cygwin.com
*** Forked() while a condition variable has waiting threads.
Report to cygwin@cygwin.com
What is the best way to print out warning messages from the DLL? If
that aspect is cleaned up, then I would change my characterization from
"ugly" to "reasonable."
My strategy is to change Cygwin (at least temporarily) to warn instead
of abort. And, then go to the python-dev list and attempt to fight that
battle. Do you concur?
Thanks,
Jason