From: | Antti Haapala <antti(dot)haapala(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Brown <kevin(at)sysexperts(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On file locking |
Date: | 2003-01-31 12:33:39 |
Message-ID: | Pine.GSO.4.44.0301311425400.26712-100000@paju.oulu.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> But this only wins if a child process inheriting an open file also
> inherits copies of any locks held by the parent. If not, then the
> issue is moot. Anybody have any idea if file locks work that way?
> Is it portable??
From RedHat 8.0 manages fork(2):
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);
DESCRIPTION
fork creates a child process that differs from the parent process only
in its PID and PPID, and in the fact that resource utilizations are set
to 0. File locks and pending signals are not inherited.
^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
And from SunOS 5.8 flock
Locks are on files, not file descriptors. That is, file
descriptors duplicated 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. Locks are not inherited by a
child process.
If I understand correctly it says that if parent dies, file is unlocked no
matter if there's children still running?
--
Antti Haapala
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2003-01-31 12:44:32 | Re: [mail] Re: Windows Build System |
Previous Message | Hannu Krosing | 2003-01-31 11:42:58 | Re: [mail] Re: Windows Build System |