On Feb 9 21:38, Corinna Vinschen wrote:
> On Feb 9 15:06, Steven Bardwell wrote:
> > > How do you test that? You're calling fcntl(F_SETLKW) exactly once at
> > > the start of your test application, but never again later. We're
> > > talking advisory file locking here, so, where's the next fcntl
On Sun, Feb 09, 2014 at 04:09:03PM -0500, Steven Bardwell wrote:
>On Sun, Feb 09, 2014 at 09:38:25PM +0100, Corinna Vinschen wrote:
>>Ok, I can reproduce it, but it's too late to debug this today.
>>
>>I have to say, though, that fcntl advisory locking is POSIX
>>functionality, while the spawn func
>
> Ok, I can reproduce it, but it's too late to debug this today.
>
> I have to say, though, that fcntl advisory locking is POSIX
> functionality, while the spawn functions are not. In fact these dreaded
> spawn entry points are rather old stuff, which hasn't been tested for a
> long time. FWI
On Feb 9 15:06, Steven Bardwell wrote:
> > How do you test that? You're calling fcntl(F_SETLKW) exactly once at
> > the start of your test application, but never again later. We're
> > talking advisory file locking here, so, where's the next fcntl call
> > waiting for the lock?
> >
> > I debugg
> How do you test that? You're calling fcntl(F_SETLKW) exactly once at
> the start of your test application, but never again later. We're
> talking advisory file locking here, so, where's the next fcntl call
> waiting for the lock?
>
> I debugged your test app and the lock still exists after the
On Feb 9 13:25, Steven Bardwell wrote:
> I have a simple programs that show the following issue:
>
> 1) program locks a file (in my test /tmp/yyy)
> 2) program then calls spawnv() (in my test"/bin/sh -c /bin/touch
> /tmp/xxx").
> 3) after the spawnv(), the file /tmp/yyy is no longer locked.
6 matches
Mail list logo
