Mail Archives: cygwin-developers/2002/08/02/09:20:25
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) ?
Thomas
- Raw text -