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


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


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