>
>> -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
an
> 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
> wrote:
>
> >
> >
> > De la: Guru Shetty [mailto:g...@ovn.org]
> > Trimis: Friday, July 15, 2016
On 14 July 2016 at 20:03, Alin Serdean
wrote:
>
>
> De la: Guru Shetty [mailto:g...@ovn.org]
> Trimis: Friday, July 15, 2016 5:49 AM
> Către: Alin Serdean
> Cc: Paul Boca ; dev@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock
>
ovs-dev] [PATCH V7] windows: Added lockf function and lock PID
file
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 pi
De la: Guru Shetty [mailto:g...@ovn.org]
Trimis: Friday, July 15, 2016 5:49 AM
Către: Alin Serdean
Cc: Paul Boca ; 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
mailto:aserd
On 14 July 2016 at 19:25, Alin Serdean
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;
[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, t
On 14 July 2016 at 15:52, Alin Serdean
wrote:
> > > +flock(filep_pidfile, LOCK_EX);
> > >
> > Won't the above call block indefinitely if the lock has already been
> taken by
> > someone else? We don't want the behavior when someone starts a daemon
> > and it simply hang there.
> [Alin Gabriel
> > +flock(filep_pidfile, LOCK_EX);
> >
> Won't the above call block indefinitely if the lock has already been taken by
> someone else? We don't want the behavior when someone starts a daemon
> and it simply hang there.
[Alin Gabriel Serdean: ] Hard to say from the MSDN documentation we could a
On 13 July 2016 at 10:35, Paul Boca wrote:
> If the PID file isn't locked then appctl.py detects it as stale and
> bails out without doing anything. Because of this lots of Python tests
> fail.
> Also this protects the PID file from being overwritten.
>
> I used only shared lock, in order to be c
Acked-by: Alin Gabriel Serdean
> -Mesaj original-
> De la: dev [mailto:dev-boun...@openvswitch.org] În numele Paul Boca
> Trimis: Wednesday, July 13, 2016 8:35 PM
> Către: dev@openvswitch.org
> Subiect: [ovs-dev] [PATCH V7] windows: Added lockf function and lock PID
>
If the PID file isn't locked then appctl.py detects it as stale and
bails out without doing anything. Because of this lots of Python tests fail.
Also this protects the PID file from being overwritten.
I used only shared lock, in order to be compatible with Python tests,
which try to acquire the lo
12 matches
Mail list logo
