Robert Collins
Sun Mar 18 13:24:00 GMT 2001

----- Original Message -----
From: "Chris Faylor" <>
To: "Robert Collins" <>
Cc: <>
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
> >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
> include the directory part of a changelog entry in any project that
> ever seen.  The only time you do this is when the directory doesn't
> 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
> >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
> did not conditionalize the thread stuff, so I did this.


> >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

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
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.
> memory is copied automatically on a fork, I'm not sure what other
> needs to be done.  I'm also not sure what the standard is for fork.
> linux duplicate every thread in a forked child?

I'll go read.

> >Secondly, the code looks broken to me with respect to
> >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.

> cgf


More information about the Cygwin-developers mailing list