From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert Collins" To: "Greg Smith" , Subject: RE: Threaded Cygwin Python Import Problem Date: Wed, 18 Jul 2001 17:56:00 -0000 Message-id: X-SW-Source: 2001-07/msg01090.html > -----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/