From: | Curt Sampson <cjs(at)cynic(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Antti Haapala <antti(dot)haapala(at)iki(dot)fi>, Kevin Brown <kevin(at)sysexperts(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On file locking |
Date: | 2003-02-01 06:11:28 |
Message-ID: | Pine.NEB.4.51.0302011509320.610@angelic.cynic.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 31 Jan 2003, Tom Lane wrote:
> Antti Haapala <antti(dot)haapala(at)iki(dot)fi> writes:
> > 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.
>
> That seems self-contradictory.
Yes. I note that in NetBSD, that paragraph of the manual page is
identical except that the last sentence has been removed.
At any rate, it seems to me highly unlikely that, since the child has
the *same* descriptor as the parent had, that the lock would disappear.
The other option would be that the lock belongs to the process, in which
case one would think that a child doing an unlock should not affect the
parent, because it's a different process....
cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2003-02-01 06:15:52 | Re: Linux.conf.au 2003 Report |
Previous Message | Curt Sampson | 2003-02-01 06:06:29 | Re: [mail] Re: Windows Build System |