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.0208020835090.217-100000@algeria.intern.net>
References: <Pine DOT WNT DOT 4 DOT 44 DOT 0208020835090 DOT 217-100000 AT algeria DOT intern DOT net>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-j8FAknYS0cEKgbUb5vHZ"
Date: 02 Aug 2002 19:19:51 +1000
Message-Id: <1028280005.8690.16.camel@lifelesswks>
Mime-Version: 1.0


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

On Fri, 2002-08-02 at 17:47, Thomas Pfaff wrote:
>=20
>=20
> On Thu, 1 Aug 2002, Robert Collins wrote:
>=20
> > On Fri, 2002-08-02 at 00:48, Thomas Pfaff wrote:
> > > While tracking down the problems with a threaded perl i recognized a
> > > problem with TLS that is probably the reason for the forked child cra=
sh:
> >
> > Good catch.
> >
> > TLS and pthread_keys are different. At worst all we need to do for
> > pthread_key support is recreate the TLS for each pthread_key, and copy
> > the value for *the forking thread*. I.E. we don't need to handle all
> > cases of TLS behaviour, and we don't need to look behind the scenes at
> > the MS thread specific data. An atfork() handler registered by
> > pthread_key_create will do this nicely, and be almost trivial to code.
> >
> > It is worthwhile checking the IEEE spec on this one before coding
> > anything, because I *thought* I had coded to that already.
> >
> > As far as supporting a win32 TLS using application that wants to fork,
> > well it's an interesting idea, but IMO inpractical. Adding fork()
> > support to WIN32 native calls is a whole project in and of itself.
> >
>=20
> Maybe i did not clarify the problem well enough. Here is is pthreaded
> sample of my code:

> The result is the same as with the previous one.=20

And? That doesn't show that my point is invalid. It does suggest that
the cygwin code does not re-register the TLS keys, but that is evident
from the current code :}.

> If the pthread keys are
> settled on Win32 Tls functions (and of course they are), than IMHO the
> easiest way is to copy the Win32 TLS array between parent and child.
> Remember that fork should create a 1:1 copy of the parent process. As
> Chris already pointed out his TLS solution is not suitable and i would
> prefer to get a working solution without reimplementing to whole Tls
> stuff.

Firstly,
Fork does *not* create a 1:1 copy of the parent process.

It creates a 1:1 copy of:
The parent global address space including loaded modules
Only a single thread, and it's stack are copied.
  That thread is the thread that calls fork().

Secondly, I suggested an alternative to *both* reimplementing TLS, and
copying the whole array. AFAICT you have not commented on that at all.
=20
> The main problem i see is to get the address of the Tls table. The
> pointer to the table seems to be located at fs (the TEB segment) at offse=
t
> 0x2c according to the MS reference, but i will dig a little deeper into
> this. Hopefully it does not vary among the different Windows versions.

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
> BTW, some news about my latest pthread patches ?

I've got a lot of stuff queued up :[. Time is becoming available
imminently.

Rob


--=-j8FAknYS0cEKgbUb5vHZ
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

iEYEABECAAYFAj1KTrcACgkQI5+kQ8LJcoLnSgCeIlUA4s1ApWT+hvGRVN0o0eqv
TQEAn2AKv4zVE1ZP133h8U4OHVNb9eA5
=G7Xy
-----END PGP SIGNATURE-----

--=-j8FAknYS0cEKgbUb5vHZ--