Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 using -f Date: Fri, 2 Aug 2002 11:57:17 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=) From: Thomas Pfaff To: cygwin-developers AT cygwin DOT com Subject: Re: RFC: TLS problem In-Reply-To: <1028280005.8690.16.camel@lifelesswks> Message-ID: 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, 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