Although Subversion tries hard to avoid the use of global or process
state in its code base, on two occasions it has been forced to delve
into that realm: once to avoid the performance overhead of creating
frequent character-set translation contexts (passing a translation
context everywhere would have served, but that would have been
cumbersome even had we realized the problem before we developed our
API), and once to deal with the problem of POSIX fcntl locks being
per-process.
APR's threading API does not provide a way of statically intializing a
mutex, which presents Subversion with a difficult conundrum when it
comes to serializing access to these global resources between threads.
One solution is for Subversion to provide initialization functions
which must be called from the single-threaded environment. That's
what we've done so far, although our compatibility rules prevent us
from making it a hard requirement for the application to call them.
Fundamentally, though, I think a requirement for initialization from
the single-threaded environment is onerous to some applications or
libraries, such as ones that have to operate within plugin frameworks.
Of course, Subversion currently passes on APR's own requirement to be
initialized from the single-threaded environment; but I think APR is
in a better position to use a statically initialized mutex to protect
itself against simultaneous initialization from multiple threads, and
I hope it will do that some day.
My idea is to provide an APR interface like:
apr_status_t apr_thread_mutex_get_named(apr_thread_mutex_t **mutex,
const char *name);
which would create or fetch from a global hash table a mutex by name.
APR can use a mutex (presumably one created by apr_initialize) to
serialize access to the hash table.
Do people think this is a reasonable feature, or have other ideas for
how to solve this sort of problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 15 02:25:54 2005