Hi Guru! I will re-spin the patch with LOCKFILE_FAIL_IMMEDIATELY flag set to avoid the hang of other daemons.
Thanks, Paul > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Guru Shetty > Sent: Friday, July 15, 2016 6:58 AM > To: Alin Serdean > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock > PID file > > On 14 July 2016 at 20:03, Alin Serdean <aserd...@cloudbasesolutions.com> > wrote: > > > > > > > De la: Guru Shetty [mailto:g...@ovn.org] > > Trimis: Friday, July 15, 2016 5:49 AM > > Către: Alin Serdean <aserd...@cloudbasesolutions.com> > > Cc: Paul Boca <pb...@cloudbasesolutions.com>; dev@openvswitch.org > > Subiect: Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock > > PID file > > > > > > > > On 14 July 2016 at 19:25, Alin Serdean <aserd...@cloudbasesolutions.com > > <mailto:aserd...@cloudbasesolutions.com>> wrote: > > > > [Alin Gabriel Serdean: ] > > https://msdn.microsoft.com/en- > us/library/windows/desktop/aa365203(v=vs.85).aspx > > The part: > > "If the same range is locked with an exclusive and a shared lock, two > > unlock operations are necessary to unlock the region; the first unlock > > operation unlocks the exclusive lock, the second unlock operation unlocks > > the shared lock." > > > > I see. Thank you. (I am blind!). I wonder whether we actually need the > > exclusive lock then? If what we need is just shared lock, why not just take > > it in the beginning? Would it have been possible to open the file in write > > mode if someone had taken the exclusive lock in the first place? > > > > [Alin Gabriel Serdean: ] No worries the MS documentation is not that easy > > to follow or precise in certain scenarios ☺. > > The problem is “Locking a portion of a file for shared access denies all > > processes write access to the specified region of the file, including the > > process that first locks the region. All processes can read the locked > > region.” > > “Locking a portion of a file for exclusive access denies all other > > processes both read and write access to the specified region of the file. > > Locking a region that goes beyond the current end-of-file position is not > > an error.” > > I agree it doesn’t make any sense why a shared lock would block the owner > > but probably they had reasons to implement it that way. > > > > What I was trying to say was, we open the file in write mode. It wouldn't > > have been successful if someone else had taken a lock (exclusive or > > shared). Am I correct? If so, why take exclusive lock again to write? Just > > write the pid and then take shared lock. Would that cause problems? (I > must > > be missing some subtlety here.) > > [Alin Gabriel Serdean: ] If we just open the file in write mode and write > > the pid and then take the shared lock, someone else could write in the file > > between the moment we opened it and gained the shared lock. > > > > Thanks, I understand it now. (I had to write a small program to get it.) I > did see though that a daemon will hang if it tries to take a exclusive lock > without LOCKFILE_FAIL_IMMEDIATELY. > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
