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: Threaded Cygwin Python Import Problem
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: Jason Tishler <jason AT tishler DOT net>
Cc: Greg Smith <gsmith AT nc DOT rr DOT com>,
        Cygwin-Developers
	 <cygwin-developers AT sources DOT redhat DOT com>
In-Reply-To: <20010907071134.F1328@dothill.com>
References: <20010907071134 DOT F1328 AT dothill DOT com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13 (Preview Release)
Date: 09 Sep 2001 15:42:13 +1000
Message-Id: <1000014135.18767.18.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 09 Sep 2001 05:29:06.0988 (UTC) FILETIME=[586C3EC0:01C138F0]

On Fri, 2001-09-07 at 21:11, Jason Tishler wrote:
> Rob,
> 
> On Fri, Sep 07, 2001 at 08:06:41AM +1000, Robert Collins wrote:
> > On Fri, 2001-09-07 at 06:25, Jason Tishler wrote:
> > > So, I patched thread.cc as follows:
> > >     @@ -622,7 +622,7 @@ pthread_mutex::pthread_mutex (pthread_mu
> > >     -  this->win32_obj_id =::CreateMutex (&sec_none_nih, false, NULL);
> > >     +  this->win32_obj_id =::CreateMutex (&sec_none, false, NULL);
> > > With a DLL containing the above patch, Greg's ftest now behaves the same
> > > as under Red Hat 7.1 Linux.  Note that Greg had a typo in his ftest.c
> > > which I fixed as follows:
> > 
> > Ah! That would be the problem then! It was very confusing to have that
> > not help at all before...
> 
> Sorry to be dense, but by "That would be the problem then!" are you
> referring to the nih security used in the CreateMutex() call or the typo
> in Greg's ftest.c?

The typo. The typo prevented the nih removal making any difference.

> Anyway after more reflection and testing under Linux, I no longer think
> that changing the security from sec_none_nih to sec_none is a good
> (if even temporary) fix.  With the above change, if a mutex is locked
> before the fork, then the behavior will be different on Cygwin and Linux.
> Under Cygwin, the child will block when it attempts to lock the mutex
> (until the parent unlocks it) while under Linux the child will not block.

The mutex shouldn't be shared (is that shourn?) across process's anyway
- unless it's a pshared mutex - which these aren't IIRC. 

> > > On Wed, Sep 05, 2001 at 06:45:16AM +1000, Robert Collins wrote:
> > > > Anyway, back to your nightmare :}. From memory what needs to happen is
> > > > that post-fork we have to iterate through all the (mutexs -again from
> > > > memory) and ensure that the win32 object is still valid. This is easily
> > > > accomplished via the pthread_atfork call - hey, we've got it, lets use
> > > > it - and a routine to fix a individual mutex - ie postforkfixup(void *p)
> > > > {pthread_mutex_t *themutex = p; ...}
> > > 
> > > Do you still think that a pthread_mutex_fixup_after_fork() is necessary?
> > > If so, could you provide more details such as:
> > 
> > Yes, but not short term. The reason is that this mutex will _behave_
> > like a broken pshared mutex - because win32 objects are global - even
> > though its a private mutex and will thus confuse more complex programs
> > (fork & wait combinations should be ok). pshared mutexs will be even
> > more broken because the process count will be wrong...
> >  
> > > 1. How to create and maintain the pthread_mutex list?
> > We don't need to.
> > > 2. How to use pthread_atfork() since you indicate it will ease
> > >    implementation?
> > At the end of pthread_mutex::pthread_mutex, after the mutex is created,
> > call pthread_atfork() - the parameters will be something like, this,
> > NULL, NULL, fixmutex. Write a function fixmutex(void *),
>                                                        ^
>                                                       +++
>
> Don't the fork handler functions take no arguments (i.e., void)?  If so,
> how can fixmutex() be associated with a specified mutex so it can fix it?

My bad. Yes you're right. It'll need a threadsafe list. Fortuneately we
have those already.
 
> > and add to the
> > end of the mutex delete function a call that finds and removes this from
> > the pthread_atfork queue. (It will need a new static helper function to
> > do that).
> 
> By "mutex delete function," do you mean the yet to be
> defined pthread_mutex::~pthread_mutex() (i.e., destructor),
> __pthread_mutex_destroy(), or some other function?

yes. :]. Any of the above really.

> > > 3. What is the exact "fixing" that postforkfixup() is suppose to do?
> > For private mutexs, create a new win32 mutex and store it in the
> > win32id. If that fails, bail out of the program.
> 
> By "bail out," do you really mean abort the program?  Ouch!

Yes. If we cannot create a new win32 object then something is
_seriously_ wrong. Forget maintaining posix semantics, think running at
all.

Rob