seth vidal wrote:
On Thu, 2008-02-21 at 09:38 -0500, James Antill wrote:
On Wed, 2008-02-20 at 22:57 -0500, seth vidal wrote:
Encountered a bug tonight that got me thinking about our locking and
some issues.
1. unless an app locks, explicitly, nothing in our current
infrastructure enforces it to happen.
2. if a user is running on their own cachedir from two different
instances the instances will happily trample over each other and do
'odd' things
3. the same is true for misbehaving root-run apps, too.
With this in mind would it be a good idea to change yum's lock mechanism
such that:
- the global lock means "the rpmdb is locked/transaction in progress"
- each repo cachedir had a lockfile that could be placed to keep that
repository dir from being changed
So I think I agree with everyone when I say automatic locking would be
awesome, but... if we try to lock each repo cachedir separately , as we
use it, can't we get deadlock due to different instances locking repo
cache dirs in a different order?
We can get delayed but I don't think we can get deadlocked.
If it gets implemented that simple we can get deadlocked quite easily.
instance 1: lock repo1
instance 2: lock repo2
instance 1: lock repo2 -> wait
instance 2: lock repo1 -> wait -> deadlock
The solution is to release all acquired locks when a lock cannot be
obtained. But this requires that there is a central place in the code that
acquires all the locks at once - otherwise see above...
Another solution is to ALWAYS acquire the locks in a certain order -
alphabetically for example. But this is a hard requirement that probably
cannot be kept by GUI applications that enable and disable repositories on
mouse click.
Another problem with automatic locking is that we need to make sure that the
locks are freed when the program is exiting - better earlier for long
running (GUI) applications. For the first some magic (on_exit_handlers) is
needed. The second will not be possible automatically at all - at least not
with the current API.
Florian
_______________________________________________
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
