This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: TLS problem


On Fri, 2002-08-02 at 17:47, Thomas Pfaff wrote:
> 
> 
> 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:

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

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

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

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

Rob

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]