Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000018 [1003.1(2008)/Issue 7] System Interfaces Objection Clarification Requested 2009-05-13 16:58 2009-06-26 14:08
Reporter ldwyer View Status public  
Assigned To
Priority normal Resolution Duplicate  
Status Closed  
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.
Attached Files

- Relationships
duplicate of 0000062Appliedajosey Is it correct to list fork as an async-signal safe interface 

-  Notes
nick (manager)
2009-05-14 09:01

What is the current implementation status of _Fork()? Is it generally available?
ldwyer (reporter)
2009-05-14 11:04

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.
geoffclare (manager)
2009-05-15 02:16

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.)
msbrown (manager)
2009-05-15 11:21

(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.)
ldwyer (reporter)
2009-05-15 11:36

(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.)
ldwyer (reporter)
2009-05-15 12:53
edited on: 2009-05-15 13:20

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.

geoffclare (manager)
2009-05-16 01:34

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.
geoffclare (manager)
2009-05-16 01:39

(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.)

- Issue History
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 02:16 geoffclare Issue Monitored: geoffclare
2009-05-15 11:00 msbrown Issue Monitored: msbrown
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
2009-09-17 06:53 tahonermann Issue Monitored: tahonermann

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