Jeroen,
then i have one more question. The real problem im trying to solve is
the 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, since
TSRM 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
