Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Subject: [Fwd: Re: Threaded Cygwin Python Import Problem]
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: cygwin-developers AT cygwin DOT com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 07 Sep 2001 08:41:16 +1000
Message-Id: <999816076.2988.18.camel@lifelesswks>
Mime-Version: 1.0

Well the cc didn't work too well :]....

Forwarded message: 
> On Fri, 2001-09-07 at 06:25, Jason Tishler wrote:
> 
> I've copied this to cygwin-developers, as the step of removing pshared
> functionality (for now) needs review...
>  
> > I was able to determine (I think) that the mutex (at least from a memory
> > contents point of view) is the same in the child as in the parent.
> > For example, the win32_obj_id value (i.e., handle) is the same in both
> > the parent and child.
> 
> the win32 obj id was always getting copied across the problem is that
> with the nih - no inherit - windows hasn't associated the handle behind
> the scenes. So while it looks like the same mutex, NT disagrees with you
> about it being a mutex :].
> 
> > I also recalled the following post from you:
> > 
> >     http://sources.redhat.com/ml/cygwin/2001-07/msg01092.html
> > 
> > So, I patched thread.cc as follows:
> > 
> >     Index: thread.cc
> >     ===================================================================
> >     RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
> >     retrieving revision 1.42
> >     diff -u -p -r1.42 thread.cc
> >     --- thread.cc	2001/08/04 21:10:52	1.42
> >     +++ thread.cc	2001/09/06 19:50:45
> >     @@ -622,7 +622,7 @@ pthread_mutex::pthread_mutex (pthread_mu
> >            return;
> >          }
> >      
> >     -  this->win32_obj_id =::CreateMutex (&sec_none_nih, false, NULL);
> >     +  this->win32_obj_id =::CreateMutex (&sec_none, false, NULL);
> >      
> >        if (!win32_obj_id)
> >          magic = 0;
> > 
> > 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...
> 
> > Unfortunately, I no longer have a NT 4.0 machine which exhibited the
> > threaded Python hang since I have subsequently upgraded it to 2000.
> > To refresh your memory, I could only reliably reproduce this hang under
> > NT 4.0 and not 2000.  Hence, I don't know whether or not I actually
> > fixed my original problem.  I'm leaning toward not since I don't think
> > that NT would deal with inherited handles any different than 2000.
> 
> Greg? I recall you built a test environment... could you try patching
> your test program as Jason has?
>  
> > Nevertheless, the above patch fixes Greg's test case.  Should I extend
> > it to include the following too?
> 
> Line numbers would be useful :}. Only alter the Create calls in the
> pthread_mutex::pthread_mutex call.
> 
> > 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 *), 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).
> > 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.
> For pshared mutex's, reestablish the handle and follow the pshared mutex
> semantics.
> 
> And once we've done this... we have to do the same for condition
> variables, events etc. Don't worry though, lets just do one at a time.
> I've had NO response to my "Does anyone use pshared mutex's", so this
> weekend I'll pull them out of thread.cc, and write up the full fix for
> you. (Now that we don't have conflicting data it should be straight
> forward).
> 
> Cheers,
> Rob
>