Re: TSRM again
| From: | Zeev Suraski | Date: | Sat, 22 Sep 2001 12:31:11 +0000 |
| Subject: | Re: TSRM again | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-66330@lists.php.net to get a copy of this message | ||
The main purpose of TSRM's resource management is to supply thread-local resources. The various macros, TSRMLS and all that, are not useful if you actually need to share a central resource between threads.
There's no real magic in sharing a central resource between threads. You have to protect it from simultaneous access, one way or another. You can use the simple portable mutex interface that's exported by TSRM:
TSRM_API MUTEX_T tsrm_mutex_alloc(void);
TSRM_API void tsrm_mutex_free(MUTEX_T mutexp);
TSRM_API int tsrm_mutex_lock(MUTEX_T mutexp);
TSRM_API int tsrm_mutex_unlock(MUTEX_T mutexp);
Zeev
At 18:23 20-09-01, lo-tek wrote:
Jeroen,then i have one more question. The real problem im trying to solve isthe ability to have multiple threads (different requests) access a resource which may be persistent. imagine, for instance, that i have a persistent database connection which matches the login criteria (username, password, host, etc) of many requests. for efficiency and resource friendliness, id want to use the same connection, but prevent the threads from mucking around with each other if they want to access/modify connection properties (which i guess is a bad idea with a persistent connection, so i may disallow modification).as i understand the TSRM code, this would not work as intended, sinceTSRM data is per thread, although there will be some reuse if the server uses thread pools to service requests. i guess at this point im talking mutexes. my only concern is (1) locking overhead (2) mutex limits. (1) is less important, since the requests will be I/O bound (2) is a concern, given the fact that theoretically at least we may have no upper limit to the number of connections spawned, though in actual practice this is limited by persistent connection reuse and an idle timeout mechanism -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net