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


On Sun, Mar 18, 2001 at 06:28:06PM +1100, Robert Collins wrote:
>Chris, managed to miss this email somehow.... I saw it while reviewing
>the dev list archives.
>
>I'm mailing you direct cc'd to the list as I've requested a subscription
>to the list, but as it hasn't been processed and I did want to answer
>the email without it getting lost. If the list bounces it could you
>please forward a copy to the list?
>
>
>
>On Sat, Mar 17, 2001 at 10:00:47AM +1100, Robert Collins wrote:
>>>Take two - return value for TimedWait function.
>>
>>I've checked this in.
>>
>>Btw, there was something strange about the patch.  Patch gave me errors
>>about missing 'diff' headers when I tried to install it.
>
>RC - strange.. I can't explain that.
>
>>Also, the ChangeLog was a little off.  There is no reason to include
>>cygwin/foo.cc in the cygwin/ChangeLog.  foo.cc is correct.  Also each
>>entry should be a sentence.
>
>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.

>>Thanks for the patch.  I am very happy to see someone working on
>>this stuff.
>>
>>Btw, is there any reason for the __pthread and pthread implementation?
>>I wasn't involved in the original implementation and I've always
>>wondered
>>why the original authors tried to do things this way.
>
>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.

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

>b) this implies that we need to recreate all the pthread_key values?

Dunno.  I'm not familiar with pthread_key.

>c) AFAICT users are able to copy pthread_key variable hither and yonder,
>so we can't just update the locations they passed us previously... so
>I'm proposing to create a mapping array (array for speed) containing
><int for user space pthread_key value>,<Tls Index> and store that
>mapping array and a mutex for it in the pinfo struct.
>then on fork, we walk the initialised entries in the array, and recreate
>them in the new process.

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?

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

cgf


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