Mail Archives: cygwin-developers/2002/08/02/09:35:56
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.
Thomas
- Raw text -