TSRM again

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