The following issue has been set as DUPLICATE OF issue 0000062.
======================================================================
http://austingroupbugs.net/view.php?id=18
======================================================================
Reported By: ldwyer
Assigned To:
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 18
Category: System Interfaces
Type: Clarification Requested
Severity: Objection
Priority: normal
Status: New
Name: Larry Dwyer
Organization: Hewlett-Packard Co.
User Reference:
Section: _Fork()
Page Number: 882
Line Number: 29307
Final Accepted Text:
======================================================================
Date Submitted: 2009-05-13 16:58 MST
Last Modified: 2009-06-26 14:08 MST
======================================================================
Summary: _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.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
duplicate of 0000062 Is it correct to list fork as an async-...
======================================================================
----------------------------------------------------------------------
(0000006) nick (manager) - 2009-05-14 09:01
http://austingroupbugs.net/view.php?id=18#c6
----------------------------------------------------------------------
What is the current implementation status of _Fork()? Is it generally
available?
----------------------------------------------------------------------
(0000007) ldwyer (reporter) - 2009-05-14 11:04
http://austingroupbugs.net/view.php?id=18#c7
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
(0000008) geoffclare (manager) - 2009-05-15 02:16
http://austingroupbugs.net/view.php?id=18#c8
----------------------------------------------------------------------
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.)
----------------------------------------------------------------------
(0000009) msbrown (manager) - 2009-05-15 11:21
http://austingroupbugs.net/view.php?id=18#c9
----------------------------------------------------------------------
(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.)
----------------------------------------------------------------------
(0000010) ldwyer (reporter) - 2009-05-15 11:36
http://austingroupbugs.net/view.php?id=18#c10
----------------------------------------------------------------------
(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.)
----------------------------------------------------------------------
(0000011) ldwyer (reporter) - 2009-05-15 13:20
http://austingroupbugs.net/view.php?id=18#c11
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
(0000012) geoffclare (manager) - 2009-05-16 01:34
http://austingroupbugs.net/view.php?id=18#c12
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
(0000013) geoffclare (manager) - 2009-05-16 01:39
http://austingroupbugs.net/view.php?id=18#c13
----------------------------------------------------------------------
(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.)
|