View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001118 | 1003.1(2016/18)/Issue7+TC2 | Base Definitions and Headers | public | 2017-01-20 13:05 | 2024-06-11 09:09 |
| Reporter | rpalethorpe | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Richard Palethorpe | ||||
| Organization | SUSE | ||||
| User Reference | |||||
| Section | fork, fcntl, flockfile | ||||
| Page Number | fork | ||||
| Line Number | 20ish | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001118: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 | ||||
| related to | 0001112 | Closed | mutex/rwlock ownership after fork is unclear |
|
|
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 |
|
|
On page 60 line 1795 section 3 add a new subsection:3.168 File Lockand 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 lockto: acquire a FILE lock |
|
|
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. |
| 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 | => 0001118: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 |
