Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
X-Authentication-Warning: atacama.four-d.de: mail set sender to <tpfaff AT gmx DOT net> using -f
Date: Fri, 2 Aug 2002 15:38:25 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=)
From: Thomas Pfaff <tpfaff AT gmx DOT net>
To: cygwin-developers AT cygwin DOT com
Subject: Re: RFC: TLS problem
In-Reply-To: <Pine.WNT.4.44.0208021526400.323-100000@algeria.intern.net>
Message-ID: <Pine.WNT.4.44.0208021537470.59-100000@algeria.intern.net>
X-X-Sender: pfaff AT antarctica DOT intern DOT net
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Fri, 2 Aug 2002, Thomas Pfaff wrote:

>
>
> On Fri, 2 Aug 2002, Thomas Pfaff wrote:
>
> >
> >
> > On Fri, 2 Aug 2002, Robert Collins wrote:
> >
> > > On Fri, 2002-08-02 at 19:57, Thomas Pfaff wrote:
> > > >
> > > >
> > > > On Fri, 2 Aug 2002, Robert Collins wrote:
> > > >
> > > > > On Fri, 2002-08-02 at 17:47, Thomas Pfaff wrote:
> > > > > >
> > > > > >
> > > > > > On Thu, 1 Aug 2002, Robert Collins wrote:
> > > > > >
> > > > > I still maintain that this is *much* harder than posix conformance.
> > > > > Coping the TLS table will mean binary compatability with every version
> > > > > of windows - and the table size at least has changed quite a bit over
> > > > > the years. Secondly we *do not know* if other .dll's register TLS
> > > > > entries during fork before the cygwin fork code does it's stuff - ie
> > > > > during DLL attaches to the new process.
> > > >
> > > > I just check my information from MSDN to the real world (NT4SP6). The
> > > > pointer at 0x2C is NULL and the TLS array is stored at TEB:0xe10.
> > > > I agree that under this condition a reimplementation of TLS for pthread
> > > > keys is easier.
> > > >
> > > > I apologize for the misunderstanding of your suggestion. I struggled
> > > > somewhere at "had coded to that already".
> > > >
> > > > I do not think that you will need pthread_atfork as long as you store a
> > > > pointer to the TLS array somewhere in the pthread class (or of course the
> > > > whole array can be taken into this).
> > >
> > > I think you still misunderstand my suggestion.
> > >
> > > My suggestion is still simpler:
> > > In pthread_key_create, we add the key to a list to be processed at fork
> > > time - just like we do for mutex's. Before a fork, we save the value for
> > > the *current* thread. After the fork we call the Win32 TLSAlloc call,
> > > and then set the TLS value to the saved value.
> > >
> >
> > The forked child will not inherit the alloced TLS from the parent because
> > this is not implemented by the runtime, but it will still use the
> > inherited keys  ?
> > Sounds strange IMHO.
> > How will you make sure that you will get the same slot for your TLS
> > values when TlsAlloc will return random numbers (the first free one) ?
>
> Aargh, things are getting clearer !
>
> You want to temporary store the value in the key list and then allocate a
> new index and store back value.
>
> I think this could be done, but it would require that the pthread_key
> class will get an additional pointer for the value and a new linked list
> with all keys and not only with keys that are associated with an
> destrutor. The destructor list will be obsolete if the destructor is added
> to the key call as well.
             ^^^^
             class