This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: pthreads


----- Original Message -----
From: "Chris Faylor" <cgf@redhat.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin-developers@cygwin.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]