Re: Re: Re: Re: Frustration with changing lock type

Hmm, I think you still have a race in the OnDestroy: if I understand flock() correctly, the lock is released as soon as you close the filehandle, so the unlink() happens after the lock has been released.

Hmm, I see what you mean. The thing is that the OnDestroy doesnt happen until after the record that this job is about is deleted from the DB. So once the deletion occurs the lockfile is more or less irrelevent as no other job can now get it. We requery the queue after every successful task, so I _think_ the race condition is covered. But maybe im wrong, and maybe there is even a better way to go about this.

Actually the more i think about it the more I think I am wrong. Hmm.

---
demerphq

_{First they ignore you, then they laugh at you, then they fight you, then you win.

-- Gandhi}

Comment on Re: Re: Re: Re: Frustration with changing lock type Download Code

Replies are listed 'Best First'.
Re^5: Frustration with changing lock type by hv (Prior) on Apr 14, 2004 at 13:02 UTC
The issue is not about _this_ record, but that you may have screwed up another process trying to handle the _next_ one. I think this would happen only if you took more than 3 seconds to process the record, so that the next process may see that the timestamp is old and grab it anyway: if it gets the LOCK_EX in the interval between you closing the file and unlinking it, it will merrily truncate and rewrite the file without knowing that anything has changed under its feet. It may be that the effect under Win32 would be that the unlink() fails, so that the new process really does have the actual file still. On a *nix system, I think it would instead have a locked filehandle on a file that is no longer linked on the filesystem, and would therefore be in danger of clashing with the next process to come and get a lock. However truncating instead should (I think) be safe either way round. Hugo	[reply]

Replies are listed 'Best First'.

Re^5: Frustration with changing lock type
by hv (Prior) on Apr 14, 2004 at 13:02 UTC

The issue is not about _this_ record, but that you may have screwed up another process trying to handle the _next_ one. I think this would happen only if you took more than 3 seconds to process the record, so that the next process may see that the timestamp is old and grab it anyway: if it gets the LOCK_EX in the interval between you closing the file and unlinking it, it will merrily truncate and rewrite the file without knowing that anything has changed under its feet.

It may be that the effect under Win32 would be that the unlink() fails, so that the new process really does have the actual file still. On a *nix system, I think it would instead have a locked filehandle on a file that is no longer linked on the filesystem, and would therefore be in danger of clashing with the next process to come and get a lock.

However truncating instead should (I think) be safe either way round.

Hugo

[reply]