WG15 Defect Report Ref: 9945-1-50
Topic: fcntl() locking


This is an approved interpretation of 9945-1:1990.

.

Last update: 1997-05-20


                                                                9945-1-90 #50
	Classification:  No change


 _____________________________________________________________________________


	Topic:			fcntl() locking
	Relevant Sections:	6.5.2.2


Defect Report:
-----------------------

       +Interpretation Request ref     : VWG/008/063092
       [Problem	description]
	      fcntl() locking

       During the development of a test	suite for ISO POSIX.1 the
       following question was raised with regard to the	fcntl()
       function	and coalescence	of adjacent locks.

       [Request	text starts] ISO/IEC 9945-1:1990 Section 6.5.2.2 fcntl() :

       Should adjacent locks be	coalesced when F_GETLK is used to
       check for existence of locks?

       X/Open would propose that they should not be so:

       In fcntl(), page	107 line 161ff of the System Interfaces	and
       headers document	it says:

	   "There will be at most one type of lock for each byte in
	   the file.  Before successfull return	from an	F_SETLK	or
	   an F_SETLKW request when the	calling	process	has
	   previously existing locks on	bytes in the region
	   specified by	the request, the previous lock type for
	   each	byte in	the specified region will be replaced by
	   the new lock	type."

       Meaning that if two locks for overlapping regions of a file
       are obtained by a single	process, the region which overlaps
       will be owned by	the new	lock. Coalescing is not	required.
       [text ends]
(Josey-X/Open)

WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------

ISO/IEC 9945-1:1990 does not specify whether there may be
distinct overlapping locks for the same process or multiple
locks of the same type on the same byte for the same process.

It is unspecified, when multiple F_SETLK or F_SETLKW requests
for the same lock type have been made by the same process that
address a common extent in the file, whether multiple requests
with F_UNLCK are necessary in order to unlock that common
extent.

Coalescing of locks is neither required nor prohibited.  It
would be conforming for an implementation to treat adjacent or
overlapping locks of the same type for the same process as if
they were coalesced immediately on creation.

Rationale for Interpretation:
-----------------------------

The request exhibits some confusion between the concepts "one
type of lock set for each byte" and "one lock set for each
byte".  POSIX.1 does not prohibit having more than one lock of
the same type on the same byte of a file for the same process.

The standard does not provide a handle by which an individual
lock may be identified after it is set.  This means that a
process can identify a lock only by the values in the struct
flock returned by an F_GETLK request.  The standard does not
require that the values returned by an F_GETLK request
correspond exactly to an extent that was locked by a single
F_SETLK or F_SETLKW request.  The specification quoted in the
request (that each byte in the file be affected by only one type
of lock) can further obscure the identity of individual locks,
since the creation of a new lock of a different type could cause
an old lock to be truncated or to be divided into discontinuous
extents.  See B.6.5.2, page 271, lines 3661-3666.

It is unspecified whether a process can use F_GETLK to identify
its own locks.  A strictly conforming application must cause the
F_GETLK request to be made from a different process.
 _____________________________________________________________________________