diff options
author | lloyd <[email protected]> | 2010-07-27 21:16:29 +0000 |
---|---|---|
committer | lloyd <[email protected]> | 2010-07-27 21:16:29 +0000 |
commit | 3531f7981256d7ff45cdcb4c96d4f339c0db1b93 (patch) | |
tree | ef09d804c147888addf6a54ebf28420157f63811 /doc | |
parent | f915a1166ed59e0822b8749eeac22b576e0f2223 (diff) |
There was an interesting bug affecting dynamically loaded engines.
The library initializer runs some self tests; this brings objects for
a few select types (AES, SHA-1, etc) into the caches. Later on, when
we add a dynamic engine, the engines aren't requeried because the
cache has hits. So, for instance an dlopen'ed engine that provided
AES-128 would not actually be used unless you called on the algo
factory with a provider of "blah" - even using set_preferred_provider
would have no effect, because that's just a request.
Add a new function to Algorithm_Cache, clear_cache, which just deletes
everything that is currently loaded (this is 90% of the destructor).
Then call this on each cache in Algorithm_Factory when a new Engine is
loaded. In normal use, this should be very fast because on init the
engines are loaded one after another so clear_cache() won't do much
work at all, but it ensures that if you load an engine later on in
runtime it will always be found. It does have the downside that the
app will then requery each Engine for each new algo after this point,
but I think typically loading a dynamic engine will happen very early
on so this won't be too much of a hassle. (And even if it happens in
the middle of execution, everything still works, it just means some
overhead the first time you ask for algo X).
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions