I once thought that was the correct way to lock an SDBM file, until someone pointed out that there's a timing window
my $db = tie(%h, 'SDBM_File', 'filename', O_RDWR|O_CREAT, 0666)
or die "Couldn't tie SDBM file 'filename': $!; aborting";
--> # right here
flock($db->fd, LOCK_EX);
At first, you'd think this wasn't a hole. But opening an SDBM file (the last time I looked) actually causes some file I/O. So what happens in this window is that two processes have read some bookkeeping data from the file into memory, one process gets the lock and proceeds to do things that side effect bookkeeping, while the other process blocks. When the first process frees the lock, the second process unblocks, but has data in memory that is now inconsistent with what's on disk. Oops.
The way around this is to use a separate file for locking, and acquire the lock before opening the SDBM file.
I may be working off of stale info, though. Can someone who has access to SDBM source confirm that significant I/O happens when the file gets opened?
| [reply]
[d/l] |
this code works on DB_FILE but not on SDBM_FILE | [reply] |
| [reply] |
