Re: fcntl file locking and pthreads

[Ville Voutilainen <vjv@ee.oulu.fi>]

> actually what I have is:
> thread 0:
> pthread_create() (1)
> pthread_create() (2)
> thread 1:
> open()
> fcntl()
> thread 2:
> open()
> fcntl()
> and they all succeed. Even though the file descriptors are different. 

Which shows us that fcntl cannot detect a file lock held by
the current process, no matter how many times we open the same
file in order to get different file descriptors. Bloody POSIX,
might I say. :) I wonder if POSIX even says anything non-vague
wrt. to this. As in, if Linux would enable detecting
two locks on two different fds (pointing to the same file)
within one process, would Linux violate POSIX? Moreover, is
this simply so that kernel detects the situation just fine,
but the info is not carried to user space because good ole
fcntl behaviour doesn't really take threads into account?
In the marvellous scheme of things (user app -> glibc -> kernel
and back), at what point (if any) is it possible to detect
multiple locks within one process? And can it be done so that
fcntl can still be claimed to be even remotely compatible
with anything on the planet?

> You digress, but I feel like I have to justify myself now :)
> Those threads used to be processes and now want be threads with minimal 
> modifications. The files that are locked are still used by other processes 
> too.

Then, logically (I suppose you already know this, but..) you
need both the file locks and mutexes to sync with both other
threads and other processes. There, one more example of how
going multi-threaded sometimes adds (mostly locking) code.

I'll shut up now, we are only at the borderline of kernel-land
and if we aim for portability, we are probably solely and
firmly on the user-land side of the big picture.

-VJV-