www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/09/11/12:37:28

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
Date: Tue, 11 Sep 2001 12:38:01 -0400
From: Jason Tishler <jason AT tishler DOT net>
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Cc: nhv AT cape DOT com, cygwin-developers AT cygwin DOT com, gsmith AT nc DOT rr DOT com
Subject: Re: fork and mutexs
Message-ID: <20010911123801.B1752@dothill.com>
Mail-Followup-To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
nhv AT cape DOT com, cygwin-developers AT cygwin DOT com, gsmith AT nc DOT rr DOT com
Mime-Version: 1.0
In-Reply-To: <1000216591.7266.254.camel@lifelesswks>
User-Agent: Mutt/1.3.18i

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 AT cygwin DOT com
    *** Forked() while a condition variable has waiting threads.
    Report to cygwin AT cygwin DOT 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019