Joe Orton wrote: > On Mon, Aug 14, 2006 at 02:55:49PM -0400, Garrett Rooney wrote: > >> I'm really just hoping for a way to make DSO loaded libraries just the >> same as any other library, if they require a whole lot of backflips to >> use reliably, that seems like a problem to me. >> > > Of course, with DSOs there are some whole new lifetime issues to think > about - it *is* difficult, no doubt about it. Nesting pools properly > and avoiding "global" pools helps with constraining the DSO to its own > little short-lived world. > > I'm not seeing anything at all here which needs changing in APR; just > some application code which has not been designed in anticipation of > being used from a DSO. That is really not something which can or should > be fixed in APR. >
This is all very well for applications, but for libraries this can be really, really difficult. I wouldn't say there's a bug in APR, but IMHO there's a huge usability problem. In the case of Subversion, we don't have much control over all the uses of our libraries and bindings. Yes, we control the command-line client, but that's really just a small part of the picture. Note that loading DSOs is not the only problem here; we have a similar issue in a case where we need a global cache, but have no control over when its created and -- most important -- when it's destroyed. We've managed to work around this particular case with horrible, hard to maintain tricks; but it would make our lives a lot easier if we could do away with them. It may not actually be necessary to add new functions to APR or anything. An acceptable solution might be to serialize allocations from the global pool, the way pool creation is serialized (IIRC). Allocating from the global pool doesn't happen very often, and if we could safely pass a NULL pool to apr_dso_load (or apr_hash_create, etc.), it think we could live with the potential performance penalty. -- Brane
