Mail Archives: cygwin-developers/2002/08/02/05:20:09
--=-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--
- Raw text -