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
Subject: Re: RFC: TLS problem
From: Robert Collins <rbcollins AT cygwin DOT com>
To: Thomas Pfaff <tpfaff AT gmx DOT net>
Cc: cygwin-developers AT cygwin DOT com
In-Reply-To: <Pine.WNT.4.44.0208021125520.309-100000@algeria.intern.net>
References: <Pine DOT WNT DOT 4 DOT 44 DOT 0208021125520 DOT 309-100000 AT algeria DOT intern DOT net>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-AjPp4M8odgWvCMSLff5j"
Date: 02 Aug 2002 23:03:02 +1000
Message-Id: <1028293382.8690.24.camel@lifelesswks>
Mime-Version: 1.0


--=-AjPp4M8odgWvCMSLff5j
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-08-02 at 19:57, Thomas Pfaff wrote:
>=20
>=20
> On Fri, 2 Aug 2002, Robert Collins wrote:
>=20
> > 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.
>=20
> 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.
>=20
> I apologize for the misunderstanding of your suggestion. I struggled
> somewhere at "had coded to that already".
>=20
> 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.

This is different from reimplementing TLS because we are still using the
win32 backed TLS call.

Rob

--=-AjPp4M8odgWvCMSLff5j
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEABECAAYFAj1KgwYACgkQI5+kQ8LJcoK5lgCfUHB5PitpN9dPN2mJ/7McgRFN
2eYAoLrybR4l7lEU7IgeWZdieUSB9b32
=RY+k
-----END PGP SIGNATURE-----

--=-AjPp4M8odgWvCMSLff5j--