FS#23501 - Finer grained and more correct locking
Attached to Project:
Pacman
Opened by Dan McGee (toofishes) - Tuesday, 29 March 2011, 16:25 GMT
Last edited by Xavier (shining) - Tuesday, 29 March 2011, 20:20 GMT
Opened by Dan McGee (toofishes) - Tuesday, 29 March 2011, 16:25 GMT
Last edited by Xavier (shining) - Tuesday, 29 March 2011, 20:20 GMT
|
Details
We could be better served by finer-grained locking on our
various writable components. It would also help a lot with
some other pending issues (cache locking,
Proposing the following: * Various locks. sync database lock (e.g. /var/lib/pacman/sync/db.lck), local database lock which would also cover writing to the whole filesystem (/var/lib/pacman/local/db.lck), cache lock(s) (present in the root of each configured pacman cache). * If we can, flock()-like semantics with exclusive vs. shared locks. * Methods to ensure we don't deadlock and acquire locks in conflicting orders, or can resolve this if it happens. * Reducing time under locks to a minimum. For an -Syu we would: - acquire sync db write lock during '-y' portion, then drop - acquire cache write lock during package/signature download, then drop - acquire local db write lock during actual upgrade process, then drop - perhaps also getting read locks during this time as well as necessary Note that cache locks and flock() might not play nice- many people could potentially use a shared NFS package cache. |
This task depends upon