Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
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
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:	<EA18B9FA0FE4194AA2B4CDB91F73C0EF08F129@itdomain002.itdomain.net.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic:	Threaded Cygwin Python Import Problem
Thread-Index:	AcEP6vd09jawU1xiT5mBix3w8INgCAAAILWg
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Greg Smith" <gsmith AT nc DOT rr DOT com>, <cygwin AT cygwin DOT com>
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/

- Raw text -