This is a complete rewrite of the now old FileUpdates class,
aiming to become easier to use and concurrently deal with.
Client code must be updated to use the new ConfigurationUpdates
class before 2012-12-31, backward compatibility won't be guaranteed
after this date.
When network is unavailable, the package file fetch function returns an error
whilst the file itself has been completely and successfully downloaded already.
With this commit it is ensured that the event is correctly handled.
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.
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__().
Never unlink() a lock when releasing it. This is quite bad when
used with shared locks.
At the same time, don't write any pid information in it, because
it's not always reliable (see previous commit).
Scenario: Process A is writing to EntropyRepository, adding new
package entries. Process B is reading from EntropyRepository,
querying for the same package entries, for example by using
retrieveKeySlot(). This method uses a dict-based cache to speed
up things, but this should be invalidated also when the mtime()
value changes.
When matching >=dev-lang/python-2.6 having some weird mask, it
can happen to end up having no matches left after the last
checkpoint. Make sure to handle the case even on the very last mile
Entropy Resources Lock file is in the etpConst['etpdatabaseclientdir']
directory. For this reason, it is better to not touch the whole
directory but just the subdirs.
unlocked_sync() works just like sync() but without acquiring the
Entropy Resources Lock. This way it's possible to externally control
the mutual exclusion.
