> On Jul 14, 2016, at 11:19 PM, Paul Boca <pb...@cloudbasesolutions.com> wrote:
>
> Hi Guru!
>
> I will re-spin the patch with LOCKFILE_FAIL_IMMEDIATELY flag set to avoid
> the hang of other daemons.
There were a few other comments too. Please have a look at them too.
>
> 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
