On Fri, Jul 25, 2008 at 8:55 AM, Geoff Clare <gwc@xxxxxx> wrote:
...
> There are deeper problems here.
and they go a long way down. It seems like what is needed is a
version of the "memory synchronization" subsection describing the
guarantees provided to and requirements expected of signal handlers.
...
> 1. The point of the "... occurs other than ..." part is (in the C
> Standard) that when a signal occurs as a result of calling abort()
> or raise(), the handler is called during execution of abort() or
> raise(), i.e. synchronously, so the rules about what things are
> async-safe do not apply. However, in a multithreaded process if one
> thread calls abort() or raise() (or kill() or sigqueue() with its
> own PID), the handler is only executed synchronously with respect to
> that thread - it is still asynchronous with respect to other threads.
> With pthread_kill() it is only synchronous with respect to the
> calling thread if it sends the signal to itself.
Hmm, the signal from kill(getpid(), sig) may be delivered to a thread
other than the current one, in which case the handler is asynchronous
with respect to the thread that called kill(). Ditto for sigqueue().
(If a call to pthread_sigmask() or sigprocmask() unblocks a signal
which is pending, is the delivery of that signal "synchronous"?)
...
> 2. The condition "if such a call fails" should not apply in POSIX.
> In the C Standard the condition is "if such a call to the signal
> function results in a SIG_ERR return". Since signal() is not allowed
> to change errno if it succeeds, errno is only indeterminate if
> signal() fails.
In the C standard, the "if such a call fails" condition is in
reference to a call to signal() for a given signal from within an
asynchronous invocation of the signal handler for that very signal.
Only then is errno indeterminate. Since POSIX goes completely beyond
the C standard in defining async-signal-safe functions and including
signal() in that set, *and* requires that access to errno be
async-signal-safe, I think that text (the last sentence of that
paragraph), should be removed.
Similarly, the last sentence of the paragraph before the one under
discussion, which places a restriction on calling raise() from a
signal handler, should be removed completely, IMHO. That comes
directly from the C standard and would appear to just be there so that
raise() doesn't have to be reentrant. Since POSIX makes raise()
async-signal-safe, restricting apps from calling it from within a
*synchronously* called signal handler seems pointless.
(...and the addition of kill(), sigqueue(), and pthread_kill() to the
list in that sentence seems like a result of mechanical
generalization, instead of true intent...)
> However, many of the POSIX async-signal-safe
> functions are allowed to change errno when they succeed. In any case,
> the part about errno needs updating to account for handlers that save
> and restore errno (as per the new application usage on the sigaction()
> page).
In particular, even though errno is not "an object declared as
volatile sig_atomic_t", it's not undefined behavior in POSIX to read
or modify it from asynchronously called signal handlers.
It's strongly tempting to suggest that the description of signal()
should just defer all these details to section 2.4.3 "signal actions".
> Additional problems are:
>
> 4. It's not clear what the phrase "the standard library" (taken from
> the C Standard) means in POSIX. Since the c99 utility's -l option
> can be used to specify certain libraries, and "-l c" is searched
> by default, "the standard library" could be taken to mean the
> equivalent of "-l c".
How about "the interfaces listed in this volume" (i.e., everything in XSH).
> So I think the paragraph should be replaced with something like:
>
> [CX]If the process is multithreaded[/CX], or if the process is
> single threaded and the signal occurs other than as the result of
> calling abort(), raise(), [CX]kill(), pthread_kill(), or
> sigqueue()[/CX], the behavior is undefined if the signal handler
> refers to any object [CX]other than errno[/CX] with static storage
> duration other than by assigning a value to an object declared as
> volatile sig_atomic_t, or if the signal handler calls any function
> defined in this standard other than [CX]one of the functions listed
> in Section 2.4 (on page xxx)[/CX].
Hmm, close. The bits about kill() and sigqueue() should only apply to
calls from this process. ("But the signal _did_ occur as the result
of calling kill(), albeit in another process...")
> [CX]Unless all signal handlers have errno set on return as it was
> on entry, the value of errno is unspecified.[/CX]
s/all/all invoked/
s/unspecified./unspecified after completion of the signal processing./
> and it should be duplicated (as normative text, without any CX shading)
> on the sigaction() page (or, alternatively, move it to XSH 2.4.3 and
> make the signal() and sigaction() pages refer to it).
The alternative makes much more sense to me, yes.
Philip Guenther
|