On Sat, 2002-10-12 at 01:23, Karl Fogel wrote:
> Let me be clearer: possibly the initialization code will need to be
> careful, sure. It will need to get a mutex on the data structure, and
> then when it has the mutex, check some flag in the data structure to
> determine if config initialization has already been completed. IOW,
> I'm certainly not saying we can ignore thread issues here, just that
> it seems to [possibly naive] me that they're quite solveable...
I'm not sure what you're proposing.
If you're saying, "Let's put locks around our initialization code,"
then:
* I think it means introducing mutex manipulation into our code for
the first time. It appears APR has thread support, but I don't know
if there are any complications from using it.
* Assuming we have a way of rereading the config files or otherwise
changing configuration data (which a GUI client could want), then
any code which accesses the configuration data will need to grab a
mutex first. That could, in theory, become a performance killer.
If you're saying, "Let's document that the caller must insure that the
initialization code is called exactly once, before anything else
happens," then we no longer have to worry about mutexes, but we've
merely pushed the problem onto the caller. If the caller is an
application, this is no problem, but if the caller is a library, now the
library has to play with mutexes when it might not otherwise have needed
to.
In general, it's more elegant, more robust, and more scalable to write
reentrant code.
Going back to the original question, though, I'm worried about the
amount of garbage going into the libsvn_client interface. This is a
very granular interface; performance-wise, no one is likely to notice if
we allocate a pool, parse a configuration file, and maybe factor a few
smallish composite numbers each time a call is made to a libsvn_client
function. However, we ask the caller to canonicalize paths, convert any
string data to UTF-8, pass in a valid pool, and now maybe pass in a
valid context as well. That may be good for the libsvn_wc interface,
which is fine-grained (yes?) and used by other libraries, but for
libsvn_client we might want to adopt a more caller-friendly convention.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 12 09:31:41 2002