Mail Archives: cygwin-developers/2001/03/18/16:29:52
----- 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
- Raw text -