I'm considering a design for Subversion where in the single-threaded environment, a pool is created and some user data is stored in it. Then, in the multithreaded environment, many threads can get (but not set) userdata within that pool.
In the current implementation, that should be safe; apr_hash_get does not modify any part of the hash table, so unsynchronized gets shouldn't run into any difficulties. However, it's not hard to imagine an implementation where it's not safe (for instance, when apr_hash_get() finds a hash entry, it could pull it to the front of the hash bucket's linked list to speed multiple accesses to the same key). Do people think it's reasonable for an application to do this? (In some ways life would be easier if a caller could lock and unlock a pool, using the same mutex which currently protects the subpool list. If I can't rely on unsynchronized gets being safe, I'll have to shuttle around a mutex along with my pool, I think.) I'm not subscribed to this list, so please cc me on replies if you don't mind. I'll check the list archives in case people don't.
