This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
[Fwd: Re: Threaded Cygwin Python Import Problem]
- To: cygwin-developers at cygwin dot com
- Subject: [Fwd: Re: Threaded Cygwin Python Import Problem]
- From: Robert Collins <robert dot collins at itdomain dot com dot au>
- Date: 07 Sep 2001 08:41:16 +1000
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
>