> That's one of the reasons, I would guess. The libc memory manager is not
> very efficient with multiple threads accessing it at once, it has locks
> (which is one of the reasons we implemented our own in ZE2). It's
> definitely one of the reasons, and as you know, performance penalties
> accumulate.
Which libc are you referring to here?
> Probably not much more than pthread_setspecific. I wouldn't be surprised
> if __thread is built around that, actually.
On Linux, there will be a huge win regarding TLS when NPTL[1]
becomes stable enough.
Today's Linuxthreads implementation uses a very simple
mechanism to maintain TLS (calculating an object's address in
software) whereas NPTL will shift this work to the
processor's MMU. I expect a big win for PHP's thread-safe
mode.
This positive effect will be automatically achieved by
continuing our use of POSIX APIs.
[1] http://people.redhat.com/drepper/nptl-design.pdf
and http://people.redhat.com/drepper/nptl/
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
