 Relationships |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
| Anonymous | Login | 2023-06-10 17:55 UTC |
| 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 | ||
| 0000062 | [1003.1(2008)/Issue 7] System Interfaces | Comment | Clarification Requested | 2009-06-26 14:02 | 2019-12-17 15:52 | ||
| Reporter | msbrown | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Applied | ||||||
| Name | Mark Brown | ||||||
| Organization | IBM | ||||||
| User Reference | |||||||
| Section | 2.4.3 | ||||||
| Page Number | 489 | ||||||
| Line Number | 16723 | ||||||
| Interp Status | Approved | ||||||
| Final Accepted Text | Note: 0000193 | ||||||
| Summary | 0000062: Is it correct to list fork as an async-signal safe interface | ||||||
| Description |
Section 2.4.3. P489 L16723 Asserts that fork() is async-signal safe. The fork() system interfaces section P882 L29311-29312 asserts that registered fork handlers are executed during the fork. P882 L 29313-29315 asserts that only async-signal safe functions are to be called by pthread_at_fork handlers to provide signal safety for fork(). The rationale section of pthread_atfork() explains the purpose of these functions. As per this section, XSH P1529, L49389-49402, it is possible that multithreaded libraries could be used by single threaded applications. In which case, atfork handlers are essential for the libraries to protect their internal state during fork. As explained further P1530, L49403-49404, pthread_atfork functions are mainly required to acquire/release mutex locks, for protecting the applications/libraries from fork() calls. C-library needs to as well have an atfork handler which acquires all the required locks to protect its memory state across fork(). The acquire/release mutex calls themselves are aync-signal unsafe operations. Use of them makes pthread_atfork handlers async-signal unsafe which in turn makes fork() async-signal unsafe when called by an application which is multi threaded, or which is linked to a library which is multi threaded. |
||||||
| Desired Action |
Need clarification with respect to 1. Is it correct to list fork as an async-signal safe interface, in a multi threaded scenario? 2. Can the implementation be allowed to not call the atfor handlers, when fork is called from a signal handler? If the atfork handlers are not going to be called when fork is called in the signal handler, then they can not be called, even if fork is called in the newly created child before exec. 3. If only async-signal safe functions are to be called from pthread_atfork handlers, then how will multi-threaded librarie protect themselves by the fork calls, made by single threaded applications linked to them? |
||||||
| Tags | issue8 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
|
Notes |
|
|
(0000121) msbrown (manager) 2009-06-26 14:03 |
We agreed not to send this down the interps track yet. The standard is clear and concerns are being forwarded to the sponsor. A previous interpretation 1003.1c-1995 #37, and also ERN XSHbug2145 have addressed the same issue, but still the problem has remained unresolved. Because of the problems which exist here it has become clear that an application using pthread_atfork(), even if the application itself did not call pthread_atfork(), may have had pthread_atfork() handlers installed by a third party library or the implementation. Therefore calling fork() from an asynchronous signal handler is undefined. Therefore we are removing fork() from the list of async-signal-safe functions. Recommendations for a future revision: A future revision should mandate posix_spawn() and add that to the list of async-signal-safe functions. Remove fork() from the list of async-signal-safe functions. [ 12 Feb 2009 - we had no consensus on the changes for a future revision] |
|
(0000122) msbrown (manager) 2009-06-26 14:06 |
Original Report: COMMENT Enhancement Request Number 15 rajani.g.k:xxxxxx Defect in XSH 2.4.3 (rdvk# 6) {GKRFORK012009} Thu, 8 Jan 2009 07:41:10 GMT |
|
(0000193) ajosey (manager) 2009-08-13 15:33 edited on: 2011-12-06 16:20 |
Interpretation response ------------------------ The standard states the requirements for fork() and async-signal safety, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor." Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Add to the end of fork() DESCRIPTION: The _Fork() function shall be equivalent to fork(), except that fork handlers established by means of the pthread_atfork() function shall not be called and _Fork() shall be async-signal-safe. Add to SYNOPSIS on fork() page: pid_t _Fork(void); and also to unistd.h Add _Fork() to the list of async-signal-safe functions Remove fork() from the list of async-signal-safe functions. |
|
(0000455) fahree (reporter) 2010-07-02 15:21 |
Isn't it what vfork was created for? fork should execute the atfork handlers, and vfork shouldn't. Problem solved. vfork can remain async signal safe and be used to implement posix_spawn or whatelse. |
|
(0000527) geoffclare (manager) 2010-08-19 15:38 edited on: 2010-08-19 15:42 |
The vfork() function had heavy restrictions on the child process. Quoting SUSv3: the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions. Therefore it is not a suitable solution to the issue of fork() async-signal-safety. |
|
(0001399) dalias (reporter) 2012-10-15 15:59 |
In regards to the future direction of making posix_spawn async-signal-safe, this change would have limited utility since the functions to build file actions operate in a way that is not feasible to make async-signal-safe; many/most real-world usages of posix_spawn need to customize the file actions just before calling posix_spawn based on newly-opened files intended for use in the spawned program. Ideally, there would be a function like posix_spawn but which takes a pointer to an array of pointers to non-opaque spawn-action structures. This design would facilitate extensibility of the spawn-action structure (using an array of pointers rather than an array of structures) and it could be constructed in an async-signal-safe manner at spawn time. It would also make it easier for implementations to add custom actions (such as changing resource limits, supplemental groups, etc.) simply by defining new macros for use in the spawn action structure, instead of requiring new functions to be added. |
|
(0001400) geoffclare (manager) 2012-10-15 16:20 |
(Response to Note: 0001399). There is no agreement to make posix_spawn() async-signal-safe. Presumably you are looking at Note: 0000121. This was superseded by Note: 0000193. To tell which bugnote has the official response, you need to look at the "Final Accepted Text" field. |
|
(0001402) dalias (reporter) 2012-10-15 16:29 |
Thanks for the tips. I saw that it was not a formal decision, just a recommendation for something to be considered in the future, and added the note so there's some record of why making posix_spawn async-signal-safe would fail to meet many applications' needs and what would be needed for a useful async-signal-safe interface analogous to posix_spawn. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-06-26 14:02 | msbrown | New Issue | |
| 2009-06-26 14:02 | msbrown | Status | New => Under Review |
| 2009-06-26 14:02 | msbrown | Assigned To | => ajosey |
| 2009-06-26 14:02 | msbrown | Name | => Mark Brown |
| 2009-06-26 14:02 | msbrown | Organization | => IBM |
| 2009-06-26 14:02 | msbrown | Section | => 2.4.3 |
| 2009-06-26 14:02 | msbrown | Page Number | => 489 |
| 2009-06-26 14:02 | msbrown | Line Number | => 16723 |
| 2009-06-26 14:03 | msbrown | Note Added: 0000121 | |
| 2009-06-26 14:06 | msbrown | Note Added: 0000122 | |
| 2009-06-26 14:08 | msbrown | Relationship added | has duplicate 0000018 |
| 2009-08-13 15:33 | ajosey | Interp Status | => Pending |
| 2009-08-13 15:33 | ajosey | Note Added: 0000193 | |
| 2009-08-13 15:33 | ajosey | Status | Under Review => Interpretation Required |
| 2009-08-13 15:35 | ajosey | Final Accepted Text | => Note: 0000193 |
| 2009-08-13 15:35 | ajosey | Resolution | Open => Accepted As Marked |
| 2009-09-17 06:51 | tahonermann | Issue Monitored: tahonermann | |
| 2009-09-17 15:41 | nick | Interp Status | Pending => Proposed |
| 2009-10-09 16:21 | ajosey | Note Edited: 0000193 | |
| 2009-10-09 16:22 | ajosey | Interp Status | Proposed => Approved |
| 2010-07-02 15:21 | fahree | Note Added: 0000455 | |
| 2010-08-12 21:45 | ldwyer | Issue Monitored: ldwyer | |
| 2010-08-19 15:38 | geoffclare | Note Added: 0000527 | |
| 2010-08-19 15:41 | nick | Relationship added | related to 0000276 |
| 2010-08-19 15:42 | geoffclare | Note Edited: 0000527 | |
| 2010-09-20 09:09 | geoffclare | Tag Attached: issue8 | |
| 2011-12-06 16:20 | geoffclare | Note Edited: 0000193 | |
| 2012-10-15 15:59 | dalias | Note Added: 0001399 | |
| 2012-10-15 16:20 | geoffclare | Note Added: 0001400 | |
| 2012-10-15 16:29 | dalias | Note Added: 0001402 | |
| 2015-04-23 23:02 | emaste | Issue Monitored: emaste | |
| 2019-12-17 15:52 | geoffclare | Status | Interpretation Required => Applied |
| 2020-07-02 13:53 | geoffclare | Relationship added | related to 0001361 |
| 2023-02-23 15:36 | eblake | Relationship added | related to 0001112 |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
