Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sun, 18 Mar 2001 12:06:54 -0500
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
Subject: Re: pthreads
Message-ID: <20010318120654.C12880@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
	cygwin-developers AT cygwin DOT com
References: <002701c0af7c$fac67710$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <002701c0af7c$fac67710$0200a8c0@lifelesswks>; from robert.collins@itdomain.com.au on Sun, Mar 18, 2001 at 06:28:06PM +1100

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