RE: Threaded Cygwin Python Import Problem

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Greg Smith [mailto:gsmith@nc.rr.com]
> Sent: Thursday, July 19, 2001 10:49 AM
> To: cygwin@cygwin.com
> Subject: Re: Threaded Cygwin Python Import Problem
> 
> 
> I quite agree.  I suppose this will require a linked structure
> pointing to locks/conditions that need to be re-initialized
> (attributes, threads/lock/condition/whatever, are probably ok?).

Yup. Which I helpfully got rid of in my rewrite :-/. Actually there was
no fixup-after-fork routine at that point in tie, but there was a fixed
size array. Sounds like we'll need a thread safe linked list like the
MTInterface::destructors list I created for pthread_atfork().
 
> But thinking of forking a threaded process makes my head hurt ;-)
> So, can I be so bold as to ask a few questions ?? I know I can
> discern the answers by RTFS, but it would help to hear the answer
> from an authoritative source, and maybe save a little research
> along the way...

RTFS would help :]. But RTFSuSv2 would help more :].
 
> In a threaded process, when fork() is issued, are all the threads
> created in the new process, or just the thread that did the fork ?

The thread that forked. No other threads are duplicated.

> I'd guess the latter; what if a separate thread owned a lock and
> was doing it's thing ? then you wouldn't want the new process to
> do the same thing thinking it owned the lock too ?  In our 
> application,

pthread_atfork() is a fork syncronisation routine that allows pthreaded
applications to prepare for fork() (ie wait for all locks to be
cleared); and then run after-fork-in-parent and after-fork-in-child
code.

> that we discussed the other day, we had a problem in 98/me where
> fork failed issued by a non-main thread, but all it wanted to do
> was asynchrously issue a shell command; it might be catastrophic if
> the threaded environment was replicated...

It's not - so no problemo. 

Rob
 
> Anyway, I'll start reading the source.
> 
> Thanks,
> 
> Greg
> 
> Christopher Faylor wrote:
> > >But, it looks like fork_copy() blindly copies everything from the
> > >original process address space to the new address space, including
> > >any pthread_mutex_t structures.
> > If that is the case then a "fixup_after_fork" routine is probably
> > required.  You can see several of those in fork.cc.
> >
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/