Re: [PHP4BETA] pthread_t as component of hash function in TSRM
| From: | Zeev Suraski | Date: | Mon, 28 Jun 1999 22:21:17 +0000 |
| Subject: | Re: [PHP4BETA] pthread_t as component of hash function in TSRM | ||
| References: | 1 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-1726@lists.php.net to get a copy of this message | ||
At 09:23 28/06/99 , Manoj Kasichainula wrote:
Rasmus suggested I take a look at the PHP4 code and make suggestions. I'm not on this list at the moment, so please cc: me on responses. One problem I noticed is that the thread ID is used to create a hash value (TSRM.c:198 in ts_resource(), for example). The problem here is that pthread_t is an opaque quantity, and isn't guaranteed to be an integer by the pthread standard, so THREAD_HASH_OF() could fail. And supposedly, pthread_t is a structure on HP-UX. For the pthread case, maybe TSRM could use the pthread TLS functions (pthread_{get,set}specific, etc.). When used with Apache, it could hash on the request_rec, or just store stuff in the request_rec. The advantage of this would be that TSRM would still work as expected under the async server models that Dean Gaudet and co. are working on.I don't want to rely on any platform specific TLSs, mainly since not every platform has TLS, and if it has it, it doesn't necessarily work right. Moreover, PHP's TSRM provides a much more powerful API than TLS by providing a just-in-time initializer and destructor for your local storage structure. Marketing aside, TSRM doesn't require the thread id to have any meaning, as long as it's unique and doesn't exchange values. This includes a pointer to a pthread_t structure, if pthread_t ends up being a structure. As long as it's ordinal, it can be used as a hash value, and I'm pretty sure we'd be able to find a thread-unique ordinal number in every multithreaded platform we port to. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il