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.

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

If I remember right, Win32 doesn't let you unlink a file while anyone still has a handle open on it

No, that is just a type of sharing that you can specify. The C RTL defaults to opening files sharing both read and write access but not sharing rename/delete access.

If you want to delete a file while you have it open in Perl, you can use Win32API::File to open the file and specify that you want to allow FILE_SHARE_DELETE.