This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: TLS problem



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).

Thomas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]