Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <007f01c0aff1$9889f110$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
References: <002701c0af7c$fac67710$0200a8c0 AT lifelesswks> <20010318120654 DOT C12880 AT redhat DOT com>
Subject: Re: pthreads
Date: Mon, 19 Mar 2001 08:22:52 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 18 Mar 2001 21:17:12.0365 (UTC) FILETIME=[CC75ADD0:01C0AFF0]

----- Original Message -----
From: "Chris Faylor" <cgf AT redhat DOT com>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin-developers AT cygwin DOT com>
Sent: Monday, March 19, 2001 4:06 AM
Subject: Re: pthreads


> On Sun, Mar 18, 2001 at 06:28:06PM +1100, Robert Collins wrote:
> >RC - noted - I ran the patch from the winsup directory, and assumed
that
> >the relative path would be relevant to the changelog as wall. -
> >different standards for different projects :].
>
> This isn't a case of different standards for different projects.  You
don't
> include the directory part of a changelog entry in any project that
I've
> ever seen.  The only time you do this is when the directory doesn't
have
> its own changelog.  winsup/cygwin has a changelog.

Squid for instance only has 1 changelog.

> >
> >RC - It looks like they wanted a clear cut line between the
externally
> >callable functions, and the actual guts. Possibly it's related to the
> >@PTH_ALLOW@ in cygwin.din. In short, I don't know.
>
> Nope.  The PTH_ALLOW is mine.  The authors of the original
implementation
> did not conditionalize the thread stuff, so I did this.

Ok.

> >BTW: I'm now looking at the pthread_key stuff, and I wanted to ask a
> >couple of questions...
> >
> >a) when a process forks, in theory the content of the entire memory
> >space, all thread state, and all pthread_key data gets copied?
>
> Thread state should not be copied since fork does not duplicate
threads.

Thanks, the opengroup specs don'y mention fork/thread interaction in the
thread call documentation - which is why I asked.

> >b) this implies that we need to recreate all the pthread_key values?
>
> Dunno.  I'm not familiar with pthread_key.

pthread_key is pretty much the same as Thread Local Storage (create a
common "variable" across all threads that each thread can use to access
a thread-specific value. Usually combined with dynamic ally allocated
memory..
pthread_key_create (pthread_key_t *, (*)(void *)) - TlsAlloc
pthread_key_delete(key) - TlsFree
pthread_setspecific - TlsSetValue
phtread_getspecific - TlsGetValue

> I guess if I knew what a pthread_key was, I might have a comment.
Since
> memory is copied automatically on a fork, I'm not sure what other
initialization
> needs to be done.  I'm also not sure what the standard is for fork.
Does
> linux duplicate every thread in a forked child?

I'll go read.

> >Secondly, the fork.cc code looks broken to me with respect to
restarting
> >all the threads that were running at the time of the fork ... Is that
> >so? If it is I'll start thinking about how to address that.
>
> Since it is not intended to restart any threads, it isn't technically
> broken.  I never intended to do this.  Doing this would be a pretty
> complicated endeavor.

ditto
>
> cgf


 Rob