RE: fcntl file locking and pthreads

[Mikhail Kruk]

> > CLONE_FILES is an argument to clone(), I'm using pthreads and I don't
> > know if LinuxThreads implementation of pthreads gives me control of
> > how clone is called. Anyway, if I understand what CLONE_FILES does,
> > it should be given to clone, because threads do have to be able
> > to share file
> > descriptors, probably. But not the locks!
> 
> 	What if I have an application where requests are written to files. Thread A
> comes along and notices a job in a file, so it locks the file and reads the
> job. The job will require some network I/O, so the thread goes on to do
> other things. Later on, thread B notices the network I/O has completed, so
> it needs to write to the file, release the lock, and close the file.

I am not persuaded by this example. Why didn't thread A close the file 
when it finished the network I/O? That would be logical time to do it. If 
it wasn't a file descriptor, but a shared memory region, would you argue 
the same about a mutex protecting that memory region?
I think this should not be a question of personal opinions or specific 
examples. It should just be consistent. Two reference platforms for 
threads are Solaris and Windows. I don't know how Solaris handles this, 
but on Windows file locks are per thread, not per process.

[Please cc]