View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000018 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2009-05-13 16:58 | 2009-06-26 14:08 |
| Reporter | ldwyer | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Duplicate | ||
| Name | Larry Dwyer | ||||
| Organization | Hewlett-Packard Co. | ||||
| User Reference | |||||
| Section | _Fork() | ||||
| Page Number | 882 | ||||
| Line Number | 29307 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0000018: _Fork() is needed to allow execution of the fork operation from a signal handler | ||||
| Description | The fork() function is not async-signal-safe in a multi-threaded process because of the requirement to execute functions registered with pthread_atfork(), which are inherently not async-signal-safe. The fork() function is listed as async-signal-safe and is executed by existing applications from signal handlers running in a multi-threaded application (this results in a deadlock). The ISV has suggested adding a new fork function that is async-signal-safe and can be executed from a signal handler that is running in a multi-threaded process. | ||||
| Desired Action | Create a _Fork function that has the same description as fork except that Lines 29307 through 29315 are deleted and replaced with: A process shall be created with a single thread. If a multi-threaded process calls fork(), the registered pthread_atfork() functions are not executed, and any mutex's or resources are duplicated. Consequently, to avoid errors, the child process of a multi-threaded process may only execute async-signal-safe operations until such time as one of the exec functions is called. | ||||
| Tags | No tags attached. | ||||
|
|
What is the current implementation status of _Fork()? Is it generally available? |
|
|
An ISV has implemented a version of _Fork (using a different function name) on all "UNIX" platforms that are of interest to that ISV. This includes AIX, HP-UX, Linux, MVS and Solaris. It is believed they also have an implementation on OS/X. System vendors have not publically committed to support this new function. |
|
|
I object to the name _Fork for this, as it is in the namespace reserved for implementations. A name clash could be a real problem for any implementor who happens to have used this name for something already. (Adding new names in the application's namespace is not a problem because of the control over visibility afforded by feature-test macros.) |
|
|
(just a meta comment - Larry, I am assuming that since this was submitted *only* to the Mantis zilla, that this is a "test" bug and not your real proposal. IF this is also your real proposal, you should submit it to the production aardvark tool as well.) |
|
|
(response to meta comment - Mark, yes, this is submitted to beta test the Mantis zilla. The real defect will be submitted in the appropriate forum. Thanks for asking.) |
|
|
The name _Fork is offered in this proposal because of the discussions that were conducted during an Austin Group phone conference. The original name, sigfork(), was considered too specific and the "function" that was being described had a relationship to fork() that is similar to the relationship between exit() and _Exit(). Opinion: Choosing _Fork, as opposed to _fork, is even less likely to required changes on the part of the implementations. In any event, the system private namespace is easier to change than the application namespace because the number of system vendors and the number of internal uses of system private functions (that may collide with an extension to the system private namespace) is much, much smaller than the application public namespace. The net-net is, the name _Fork was not chosen solely to preclude namespace pollution, it was to follow already established convention in the Standard. |
|
|
On second thoughts, I retract my previous comment. Choosing a name in the application's namespace has just as much potential to cause problems for implementors as _Fork() does. (E.g. if we call it sigfork() and an implementation already has a sigfork() function.) The complication for applications if we call it sigfork() would be in addition to any complication for implementors, rather than instead of it. |
|
|
(response to meta comment - there is already an aardvark for this, namely xshbug3 ERN 15. Once the changes to go in the next revision have been agreed, they should be entered in that aardvark and it should be sent down the interps track.) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-05-13 16:58 | ldwyer | New Issue | |
| 2009-05-13 16:58 | ldwyer | Name | => Larry Dwyer |
| 2009-05-13 16:58 | ldwyer | Organization | => Hewlett-Packard Co. |
| 2009-05-13 16:58 | ldwyer | Section | => _Fork() |
| 2009-05-13 16:58 | ldwyer | Page Number | => 882 |
| 2009-05-13 16:58 | ldwyer | Line Number | => 29307 |
| 2009-05-14 09:01 | nick | Note Added: 0000006 | |
| 2009-05-14 11:04 | ldwyer | Note Added: 0000007 | |
| 2009-05-15 02:16 | geoffclare | Note Added: 0000008 | |
| 2009-05-15 11:21 | msbrown | Note Added: 0000009 | |
| 2009-05-15 11:36 | ldwyer | Note Added: 0000010 | |
| 2009-05-15 12:53 | ldwyer | Note Added: 0000011 | |
| 2009-05-15 13:20 | ldwyer | Note Edited: 0000011 | |
| 2009-05-16 01:34 | geoffclare | Note Added: 0000012 | |
| 2009-05-16 01:39 | geoffclare | Note Added: 0000013 | |
| 2009-06-17 14:04 | msbrown | Tag Attached: real bug in aardvark | |
| 2009-06-26 14:08 | msbrown | Relationship added | duplicate of 0000062 |
| 2009-06-26 14:08 | msbrown | Status | New => Closed |
| 2009-06-26 14:08 | msbrown | Resolution | Open => Duplicate |
| 2009-08-13 15:11 | msbrown | Tag Detached: real bug in aardvark |
