Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001118 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Comment Clarification Requested 2017-01-20 13:05 2024-06-11 09:09
Reporter rpalethorpe View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Richard Palethorpe
Organization SUSE
User Reference
Section fork, fcntl, flockfile
Page Number fork
Line Number 20ish
Interp Status ---
Final Accepted Text Note: 0004061
Summary 0001118: Clarify meaning of "file lock"
Description In http://pubs.opengroup.org/onlinepubs/9699919799/ [^] (fork) it states that "File locks set by the parent process shall not be inherited by the child process.".

As far as I can tell, the phrase 'file lock', is not explicitly defined and there are at least two types of lock which could be described as a 'file lock'. One is the type of lock established by fcntl(), which states in its rationale that locks are not inherited through fork(). The other is a lock established by flockfile() which makes no mention of fork().

Furthermore, in this context, the term 'inherited' could be taken to mean that the lock's data structures are copied to the child or that the ownership of the lock is inherited by the child (i.e. the child can access a file locked by the parent) or that the child is subject to restrictions imposed by the locks (i.e. it can't access a locked file).

This may or may not be related to: http://austingroupbugs.net/view.php?id=1112 [^]
Desired Action 1. Explicitly state the types of lock meant by 'file lock'
2. Elaborate on the term 'inherit' in the context of file locks during a process fork or cite its definition.
Tags tc3-2008
Attached Files

- Relationships
related to 0001112Closed mutex/rwlock ownership after fork is unclear 

-  Notes
(0003558)
rpalethorpe (reporter)
2017-01-20 14:36

 This issue is an active source of confusion as a fork() test within the LTP/Open POSIX test suite has used one interpretation and glibc has used another. The test passes on older versions of glibc, but has now begun to fail.

Related discussion: https://bugzilla.novell.com/show_bug.cgi?id=1018908 [^]
(0004061)
geoffclare (manager)
2018-07-26 16:06

 On page 60 line 1795 section 3 add a new subsection:
3.168 File Lock

A lock obtained on a file through the use of fcntl() or lockf().
and renumber the later 3.x subsections.

On page 874 after line 29515, add to flockfile APPLICATION USAGE:
Note: a FILE lock is not a file lock (see XREF to XBD 3.168).

On page 875 line 29518 section flockfile(), change:
acquire a file lock
to:
acquire a FILE lock
(0004063)
shware_systems (reporter)
2018-07-26 16:42

 Additional note based on phone discussion:
page 497 line 17271:
Note that after a fork( ), two handles (Ed: either file descriptor or FILE * in this context) exist where one existed before. The application shall ensure that, if both handles can ever be accessed, they are both in a state where the other could become the active handle first. The application shall prepare for a fork( ) exactly as if it were a change of active handle. (If the only action performed by one of the processes is one of the exec functions or _exit( ) (not exit( )), the handle is never accessed in that process.)

This apparently includes it being the application's responsibility to unlock any locks established by fcntl() or f(try)lockfile() on the stream, whether the application is single or multi-threaded, before attempting the call to fork() so either parent or child process may establish a new lock without blocking, if desired, and otherwise the behavior is undefined.

- Issue History
Date Modified Username Field Change
2017-01-20 13:05 rpalethorpe New Issue
2017-01-20 13:05 rpalethorpe Name => Richard Palethorpe
2017-01-20 13:05 rpalethorpe Organization => SUSE
2017-01-20 13:05 rpalethorpe Section => fork, fcntl, flockfile
2017-01-20 13:05 rpalethorpe Page Number => fork
2017-01-20 13:05 rpalethorpe Line Number => 20ish
2017-01-20 14:36 rpalethorpe Note Added: 0003558
2018-07-26 15:11 nick Relationship added related to 0001112
2018-07-26 16:06 geoffclare Note Added: 0004061
2018-07-26 16:07 geoffclare Interp Status => ---
2018-07-26 16:07 geoffclare Final Accepted Text => Note: 0004061
2018-07-26 16:07 geoffclare Status New => Resolved
2018-07-26 16:07 geoffclare Resolution Open => Accepted As Marked
2018-07-26 16:08 geoffclare Tag Attached: tc3-2008
2018-07-26 16:42 shware_systems Note Added: 0004063
2019-10-30 10:58 geoffclare Status Resolved => Applied
2024-06-11 09:09 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker