Mail Archives: cygwin-developers/2001/03/18/12:06:45
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
- Raw text -