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