Completely move the arbitration to RigoDaemon, making Rigo passively
accepting the former requests.
Moreover, complete support for bottom notification area and start
implementing app management events.
- Add User notifications before blocking on semaphores
- Fix several minor glitches related to features introduced the
past week
- Cleanup rigo.enums from Software Center crapcode
- Improve Progress Bar interaction with User
- Introduce Activity states and busy(), unbusy() methods to allocate
and deallocate Daemon activities from the Clients, concurrently.
- Tokenize acquire_resources() and release_resources() to filter out
older events. The same token is returned to Clients via signals whenever
it makes sense (repositories_updated() is one of them).
- Implement Repositories Update Activity resume functionality in Rigo.
It is possible to close Rigo during a repo update and reopen it afterwards.
Multiple Rigo instances are allowed as well.
- Implement the ability for RigoDaemon to kindly request Rigo Clients
to release their locks (either shared or exclusive) due to new activity
being scheduled.
All the races and possible deadlocks should be handled correctly,
but due to the actual complexity, only time will tell.
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).
in Entropy Client library functions, we currently check if current
pid equals the one stored inside .using_resources file if lock
cannot be acquired in blocking mode. This is bad because the information
is not 100% reliable. The trick was there in order to allow equo
to exec*() without releasing the file locks. However, there could
be a race between lock and unlock Entropy Client methods that could
cause the former to unlink() a still valid lock file. This happens
now due to the introduction of non-exclusive locking support.
Get rid of all this shit then!
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.
Fabio Erculiani