Entropy Resouce Locks are reentrant, thus reference counted on lock()
and unlock() operations. For this reason, the counter must be increased
on every lock() request. This did not happen if the lock was already
held by the process with the unwanted effect of improperly releasing it.
This caused the "Calculating dependencies" glitch on each package
transaction.
reload() is going to be used during RigoDaemon package
upgrade to kindly ask the Dbus service to reload itself as soon as
no more clients are connected.
Closing the underlying sqlite3 db on object destruction (__del__())
causes funny race conditions when concurrently accessing the object
itself.
When the Garbage Collector tries to free memory, which can happen
when no more references pointing to self are used, by calling __del__()
(which called close()) it is possible to run into troubles if another
thread is inside a method of the same object holding a valid sqlite cursor.
Moreover, no external arbitration is possible if the garbage collection
gets in the middle and calls close() through the destructor on behalf
of a poor random innocent thread.
Solution is simple, destructor is evil and resource leaks have to be
handled where they actually are. Bye bye __del__().
The ReadersWritersSemaphore object protects concurrent access
on EntropyRepository objects ensuring that they don't get closed
by RigoServiceController while in use.
There are two issues with Entropy Resources Lock when used in Rigo.
1. Reentrancy: this property is unwanted in Rigo due to the amount
of time Entropy Resources Lock is acquired and released.
It is always wanted to acquire once and release once.
2. Re-acquiring it is costly, this lock should be relased only when
we are really forced to do so.
Now that Entropy Resources are completely handled by RigoDaemon
in its activity code, there is no need to keep pinging clients
unless SIGUSR2 arrived.
SIGUSR2 signal will be later used to force RigoDaemon shutdown
in case of rigo package updates via Entropy, to avoid having incompatible
RigoDaemon versions running.
Fabio Erculiani