Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Threaded Cygwin Python Import Problem X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Thu, 19 Jul 2001 10:45:31 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Threaded Cygwin Python Import Problem Thread-Index: AcEP6vd09jawU1xiT5mBix3w8INgCAAAILWg From: "Robert Collins" To: "Greg Smith" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id VAA30544 > -----Original Message----- > From: Greg Smith [mailto:gsmith AT nc DOT rr DOT com] > Sent: Thursday, July 19, 2001 10:49 AM > To: cygwin AT cygwin DOT 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/