Re: On file locking

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

In response to

Responses

Browse pgsql-hackers by date

  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