Hi, On Monday 18 August 2008 22:26:20 Stanislav Malyshev wrote: > Hi! > > > The following patch caches each global address in a native TLS variable so > > that accessing a global is as simple as global_name->member. This removes the > > requirement of passing the tls pointer across function calls, so that the two > > major overheads of ZTS builds are avoided. > > I think it would be great to use __thread there. But I think if we have > working __thread, why not have real globals use it, without all that > TSRMG stuff? Having 3 different variants of TSRM support seems excessive.
I'm agree with you, but actually TSRM does more that just allocating and storing globals. For instance it keeps track of constructors and destructors so that it can call them automatically when a new thread starts or stops. It also allows to retrieve the globals of an other thread, etc. > > Now, the question is can we reliably detect if we have working __thread > - or, in other words, are there compilers which would accept __thread > but do not implement it correctly, and can those be identified > automatically? For that I checked how the glibc chooses to use __thread or not. Actually it just tries to compile a source like I do in the patch. But as TLS handling needs the help of the libc itself, and the glibc knows it can handle TLS, I guess we will need to do write a more complete test to check if it works and if it works as we expect it to work. > > If we use static declaration with __thread, then as far as I can see > there is no need for separate IDs and all complications following from > that. > > > - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles > > to dlopen(), actually Apache wont load the module at runtime (it works with > > just --with-tsrm-__thread-tls). > > What is the problem there, could you elaborate? > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
