Re: On file locking
От | Kevin Brown |
---|---|
Тема | Re: On file locking |
Дата | |
Msg-id | 20030201163103.GO12957@filer обсуждение исходный текст |
Ответ на | Re: On file locking (Curt Sampson <cjs@cynic.net>) |
Ответы |
Re: On file locking
Re: On file locking |
Список | pgsql-hackers |
Curt Sampson wrote: > On Fri, 31 Jan 2003, Shridhar Daithankar<shridhar_daithankar@persistent.co.in> wrote: > > > Besides file locking is implemented using setgid bit on most unices. And > > everybody is free to do what he/she thinks right with it. > > I don't believe it's implemented with the setgid bit on most Unices. As > I recall, it's certainly not on Xenix, SCO Unix, any of the BSDs, Linux, > SunOS, Solaris, and Tru64 Unix. > > (I'm talking about the flock system call, here.) Linux, at least, supports mandatory file locks. The Linux kernel documentation mentions that you're supposed to use fcntl() or lockf() (the latter being a library wrapper around the former) to actually lock the file but, when those operations are applied to a file that has the setgid bit set but without the group execute bit set, the kernel enforces it as a mandatory lock. That means that operations like open(), read(), and write() initiated by other processes on the same file will block (or return EAGAIN, if O_NONBLOCK was used to open it) if that's what the lock on the file calls for. That same documentation mentions that locks acquired using flock() will *not* invoke the mandatory lock semantics even if on a file marked for it, so I guess flock() isn't implemented on top of fcntl() in Linux. So if we wanted to make use of mandatory locks, we'd have to refrain from using flock(). -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: