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 script finishes). > - 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. Gustau _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"