Re: Threaded Cygwin Python Import Problem

[Jason Tishler <jason at tishler dot net>]

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?

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.

> > 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.

I should have given more context for the above, but I think that extending
the patch to cover semaphores, etc. is now moot.

> > 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?

> 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?

> > 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!

Thanks,
Jason