David Malone wrote:
> On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote:
>
>> From the manual page for flock:
>>
>> NOTES
>> Locks are on files, not file descriptors. That is, file descriptors du-
>> plicated through dup(2) or fork(2) do not result in multiple instances of
>> a lock, but rather multiple references to a single lock. If a process
>> holding a lock on a file forks and the child explicitly unlocks the file,
>> the parent will lose its lock.
>
> Doesn't this make it impossible to hold a lock on a file when you
> want to fork a child to do some task 'cos the lock will be dropped
> when the child closes its copy of the file discriptor on exit?
> Either it's a posix goof or the lock shouldn't be let go until
> either explicitly released or the last instance of the file discriptor
> is closed?
The lock doesn't seem to be released until *explicitly* released, like
the manual page says. I don't think closing the descriptor counts as
an explicit unlock, though I am probably wrong. Run this program,
you'll see the parent still has the lock. Change close(fd) to flock(fd,
LOCK_UN) and you'll see it doesn't. It's possible I've misunderstood
something though.
#include <fcntl.h>
#include <err.h>
#include <stdio.h>
#include <unistd.h>
int
main(void) {
int fd;
fd = open("lock", O_CREAT|O_RDWR, 0600);
if (fd < 0)
err(1, "open");
if (flock(fd, LOCK_EX) != 0)
err(1, "flock");
switch (fork()) {
case -1:
err(1, "fork");
case 0:
close(fd);
_exit(0);
default:
sleep(2);
break;
}
system("lsof | less");
return (0);
}
--
Ben Smithurst | PGP: 0x99392F7D
[EMAIL PROTECTED] | key available from keyservers and
| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
