A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1118 ====================================================================== Reported By: rpalethorpe Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1118 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: Resolved Name: Richard Palethorpe Organization: SUSE User Reference: Section: fork, fcntl, flockfile Page Number: fork Line Number: 20ish Interp Status: --- Final Accepted Text: http://austingroupbugs.net/view.php?id=1118#c4061 Resolution: Accepted As Marked Fixed in Version: ====================================================================== Date Submitted: 2017-01-20 13:05 UTC Last Modified: 2018-07-26 16:42 UTC ====================================================================== Summary: Clarify meaning of "file lock" ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001112 mutex/rwlock ownership after fork is un... ======================================================================
---------------------------------------------------------------------- (0004063) shware_systems (reporter) - 2018-07-26 16:42 http://austingroupbugs.net/view.php?id=1118#c4063 ---------------------------------------------------------------------- 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 <i>fcntl</i>() or <i>f(try)lockfile</i>() on the stream, whether the application is single or multi-threaded, before attempting the call to <i>fork</i>() 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 => http://austingroupbugs.net/view.php?id=1118#c4061 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 ======================================================================
