El 11/03/16 a les 15:30, Gustau Pérez ha escrit:
Answering myself again:
> I guess the locks need to be released before the hotplug finishes or
> there would be stale locks in the system.
This is not entirely true. The holds would be dropped when then
hotplug script finishes (the fd will be closed by the system when the
> - I'll ask you something about the advisory locks. Perhaps this
> evening if I find some time to spend.
The previous question (in this mail) leaded me to think that perhaps
the locking facility is a bit complex. Please correct me if I'm wrong:
1. But we only need to keep track of the lock files created by a
hotplug script during its execution, right? :
2. If the script does its job, the hotplug script should release the
locks it is holding once its job is done, right?
3. If the domain has two disks defined, the hotplug script would be
called two times, right? If that's so, I don't see how during the
second execution of the hotplug script the _lockdict array in
locking.sh would have the values of the first execution.
4. The hotplug scripts needs to keep track of the lock it holds, that
would help the script to release only the lock it holds and not
other locks. This is way the _lockdict array is needed.
In fact, because the hotplug script should release the locks it has
acquired before finishing, I think it would be enough to keep track of
the locking files a hotplug script has created (no the fd's) and use the
timeout argument of the lockf. If a second domain tries to lock a file,
it should loop waiting a fixed amount of time until the lock becomes
available. If it becomes available is because:
1. The holder released the lock by calling release_lock
2. Or the holder finished its work a called exit
* *Either way the lock would be available.
I don't understand why the Linux locking script seems that complex.
Perhaps I'm missing something, if anyone sees the point, please let me know.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"