Revisions 0 to 10 in in which 'src/libstate.cpp' was changed are listed below. These revisions are ancestors of the revision [395d2422..]. The "diff" links listed with each revision will show changes in 'src/libstate.cpp' between that revision and [395d2422..].

403 days ago: Move most of the initializer code directly into the Library_State constructor
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Move most of the initializer code directly into the Library_State constructor
Date: Sat, 13 Oct 2007 20:11:51 GMT
409 days ago: If we attempt to access the global state, and it is null, call
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog:
If we attempt to access the global state, and it is null, call
LibraryInitializer::initialize(), which will set it for us (or fail by
throwing an exception, which will be propogated to the caller). So any
instances of creating a LibraryInitializer where no option arguments
are passed can be removed; instead that initialization will run when
or if you execute an operation where Botan requires the services
provided in the state. Because no options are passed, the library will
be using the default (debug and not thread safe) mutex type: so
hopefully you'll quickly get an exception when the debug mutex
realizes it is being used in a threaded application, but there is risk
of operations silently failing before that happens.
You can call LibraryInitializer::deinitialize() at the end of your
main function (or whenever you think you won't need Botan anymore), to
free the global state; if not a number of cleanup destructors will not
run (including the final scrub of memory).
You can even shut down Botan speculatively; if it turns out you need
it again, it just means you'll have to take the cost of another
initialization. However in applications that use Botan only in small
bursts, or in rarely taken codepaths, you can remove the state
entirely and suffer zero memory overhead. This probably only makes
sense in memory constrained systems, but it's reasonable to do now.
Speculatively deallocating the state is probably not thread safe
without extra work. One thread calling deinitialize() would invalidate
pointers that would have been visible to other threads. One (untested)
idea: have an atomic integer with the number of current threads using
Botan. If any thread decrements and hits zero, it could deinitialize
Botan safely. This might cause too many repeated startup/shutdowns,
which would depend on the app use pattern.
In addition, since you can't pass arguments to the new Library_State,
you can't specify the use of real mutexes (or anything else): so for
right now, this only works in applications that are fine with the
standard options. I want to find a way to get that working, though,
since it's very inelegant. Currently a Default_Mutex (not at all
thread safe but somewhat error checking) will be used. And self test
will always be run (more on that below).
I wrote a program that just initializes and shuts down in a tight
loop. Running on my Gentoo box (Core2 E6400, gcc 4.1.2):
thread_safe? selftest? time (ms)
------------ --------- ---------
no yes 6.1
no no 3.8
yes yes 6.7
yes no 3.8
If you're actually worried that the library might start up OK but then
start failing basic self tests, what you actually want to do is have a
thread that runs diagnostics on your entire process state (including
calling Botan's self test code) every N seconds.
The question is how to get arguments from the outside world to the
constructor of the Library_State that is created inside of
global_state(): avoiding many self tests to save a bit of time (many
applications won't care about the extra cost but sometimes 2 or 3 ms
is important), and thread safety (beacuse you can't specify to use a
real mutex).
Date: Sun, 07 Oct 2007 22:53:59 GMT
627 days ago: Use prefix rather than postfix increment in places where it can be used.
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Use prefix rather than postfix increment in places where it can be used.
Date: Sat, 03 Mar 2007 23:46:18 GMT
631 days ago: Remove a call to abort() in global_state() which was triggered if no
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Remove a call to abort() in global_state() which was triggered if no
global state pointer was set. Presumably I put that there for debugging
at some point and let it escape.
Date: Wed, 28 Feb 2007 02:37:13 GMT
670 days ago: Bump copyright year to 2007
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Bump copyright year to 2007
Date: Sat, 20 Jan 2007 10:54:11 GMT
707 days ago: Move the UI pulse functions into the global library state. That is (as best
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Move the UI pulse functions into the global library state. That is (as best
as I can tell) the last of the global data, with the exception of the single
global_lib_state pointer in libstate.cpp
Date: Thu, 14 Dec 2006 11:12:32 GMT
792 days ago: The public add_engine API now always places the new engine at the front
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: The public add_engine API now always places the new engine at the front
of the list. The only time when the other behavior was desired was inside
the load() function, which now simply appends to the engines vector itself.
Date: Wed, 20 Sep 2006 08:19:23 GMT
801 days ago: Correctly deal with allocators added post-initialization. In particular,
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Correctly deal with allocators added post-initialization. In particular,
handle the case where an allocator is added that has the same name as one
already registered.
Flush the cached allocator pointer when the default is changed.
Mark comparison operations in Pooling_Allocator::Memory_Block as inline;
this seems to help the STL sort and binary search algorithms tremendously.
Date: Mon, 11 Sep 2006 00:44:28 GMT
834 days ago: Remove memory leak - the configuration object was not being deleted.
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Remove memory leak - the configuration object was not being deleted.
Date: Wed, 09 Aug 2006 05:17:30 GMT
838 days ago: Make it possible to insert Engines into the front of the queue;
view file | diff | revision info | browse files
Author: lloyd@randombit.net
Changelog: Make it possible to insert Engines into the front of the queue;
otherwise any Engines added after startup (eg, application-specific
ones) would only be used for new algorithm - it wouldn't be possible
for them to override existing implementations.
Date: Sat, 05 Aug 2006 11:38:34 GMT