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
X-Authentication-Warning: atacama.four-d.de: mail set sender to <tpfaff AT gmx DOT net> using -f
Date: Fri, 2 Aug 2002 09:47:12 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=)
From: Thomas Pfaff <tpfaff AT gmx DOT net>
To: cygwin-developers AT cygwin DOT com
Subject: Re: RFC: TLS problem
In-Reply-To: <1028214797.7511.37.camel@lifelesswks>
Message-ID: <Pine.WNT.4.44.0208020835090.217-100000@algeria.intern.net>
X-X-Sender: pfaff AT antarctica DOT intern DOT net
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Thu, 1 Aug 2002, Robert Collins wrote:

> 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 crash:
>
> 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.
>

Maybe i did not clarify the problem well enough. Here is is pthreaded
sample of my code:

#include <stdio.h>
#include <pthread.h>

int main(void)
{
  pthread_key_t p_key;

  pthread_key_create (&p_key,NULL);
  pthread_setspecific (p_key, (void*) 0x10);

  switch (fork())
    {
    case -1:
      return 0;
    case 0:
      printf ("child:  %p\n", pthread_getspecific (p_key));
      break;
    default:
      wait (NULL);
      printf ("parent: %p\n", pthread_getspecific (p_key));
    }

  return 0;
}

The result is the same as with the previous one. 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.

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

BTW, some news about my latest pthread patches ?

Greetings,
Thomas