On Thu, 03.01.13 23:21, Stef Bon ([email protected]) wrote: > Yes, thanks a lot. I've read it, understood, maybe this whole locking thing > should be replaced with a better approach. First you mention in the first > blog entry: > > "Mandatory locking is available too. It's based on the POSIX locking API > but not portable in itself. It's dangerous business and should generally be > avoided in cleanly written software. > " > > Now, what do you mean? I think that mandatory locking is actually better. A > lock by definition is a way to prevent other processes/threads to use a > specific range in a file. What's the use of it when it's not mandatory? > I've read the paper: > > http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
Well, on Linux file access is generally considered "fast", i.e. it's always synchronous and difficult to distuingish from access to allocated memory backed by swap... Mandatory locking also gets really weird when mmap() is used. Then, you open up an entirely new can of worms when it comes to security: i.e. when somebody can take a mandatory lock on a file he can block everybody else, and they can't do anything against this, and end up hanging just because they tried to read a file. Advisory locking at least has the benefit that everybody knows that it might block, and that they are actually specifically are calling it to block. Also see fcntl(2) man page in this regard, the section about Mandatory Locking and the one about Bugs. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
