Re: Locking in C++
From: amsa (amsavarthini_at_yahoo.com)
Date: 08/30/04
- Next message: vertigo: "ncurses: getting pad rows"
- Previous message: Andrew Falanga: "Re: equivalent to far in linux/unix"
- In reply to: Nils Weller: "Re: Locking in C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Aug 2004 08:39:41 -0700
how does fcntl() function differ from the traditional lockf()
function.
even if the file is locked by fcntl or lockf, another process can
always read a locked file.
av.
Nils Weller <me@privacy.net> wrote in message news:<2pe7egFk298pU1@uni-berlin.de>...
> In article <41318407$0$2917$d5a6236f@newsreader.cybernetik.net>,
> Kristofer Pettijohn wrote:
> > What are people using to lock files in C++ these days?
> >
> > The OS I'm mainly using is FreeBSD 5.2.1, GCC 3.3.3, and of course, in
> > C++ with [io]?fstream.
>
> POSIX and UNIX are based on C - they do not even know C++ I/O streams.
> But it's even worse than that; The locking functions provided to obtain
> a lock operate on file descriptors, not file streams.
>
> That said, what you want is the fcntl() function because this way is the
> most portable one (the traditional System V way was lockf() and the
> traditional BSD way was flock(). The latter is even part of SUSx, the
> former is not.)
>
> Here's how you write lock an entire file using fcntl():
>
> struct flock f;
> int fd;
>
> if ((fd = open("file", O_RDWR)) == -1) {
> /* Error */
> }
> f.l_type = F_WRLCK;
> f.l_whence = 0;
> f.l_start = SEEK_CUR;
> f.l_len = 0;
> f.l_pid = getpid();
> if (fcntl(fd, F_SETLK, &f) == -1) {
> /* Error */
> }
>
> There are two important things to note here. First of all, there is a
> distinction between ``advisory locking'' and ``mandatory locking''. An
> advisory lock is intended to be used between a group of friendly
> processes who voluntarily check every file they access for such a lock.
> If they do not check for lock requests or do not listen to them, they
> are free to use the file as they wish, despite the lock. Advisory
> locking is the default, so if you intend to prevent unrelated processes
> who are unaware of your intentions from using the file, you will need to
> turn on mandatory locking.
>
> Mandatory locking is enforced by the kernel and cannot be ignored. In
> order to turn on mandatory locking on a file, a file permission kludge
> is used: If you turn on the set-gid bit and turn off the group
> executable bit of the file, then every subsequent lock on it will be
> mandatory. Note that this kind of locking is not as widespread as
> advisory locking; Modern BSD systems for one do not support it.
>
> The second point is that you must keep the file descriptor you used to
> obtain the lock open. As soon as you close it, the lock(s) is (are) gone
> as well.
- Next message: vertigo: "ncurses: getting pad rows"
- Previous message: Andrew Falanga: "Re: equivalent to far in linux/unix"
- In reply to: Nils Weller: "Re: Locking in C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
