This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 2/3] Consolidate Linux sigprocmask implementation (BZ #22391)
On 15/11/2017 23:16, Rical Jasan wrote:
> Just one final nit.
>
> On 11/15/2017 09:54 AM, Adhemerval Zanella wrote:
>> diff --git a/manual/signal.texi b/manual/signal.texi
>> index 9577ff0..4f0ef59 100644
>> --- a/manual/signal.texi
>> +++ b/manual/signal.texi
>> @@ -235,6 +235,7 @@ defined. Since the signal numbers are allocated consecutively,
>> * Job Control Signals:: Signals used to support job control.
>> * Operation Error Signals:: Used to report operational system errors.
>> * Miscellaneous Signals:: Miscellaneous Signals.
>> +* Internally-Used Signals:: Signals used internally by the C library.
>> * Signal Messages:: Printing a message describing a signal.
>> @end menu
>>
>> @@ -794,6 +795,26 @@ in @ref{Signaling Another Process}.
>> The default action is to terminate the process.
>> @end deftypevr
>>
>> +@deftypevr Macro int SIGRTMIN
>> +@deftypevrx Macro int SIGRTMAX
>> +@standards{POSIX.1, signal.h}
>> +@cindex real-time signals
>
> This @cindex should go above the @deftypevr to ensure the reader lands
> above the heading. Much of the time the difference probably won't be
> noticeable, but it's annoying when you run into that off-chance of it
> being on some weird boundary. The Texinfo manual does mention keeping
> index entries above "visible material" [1].
Ack, I have changed it locally.
>
>> +The range of signal numbers @code{SIGRTMIN}, @code{SIGRTMIN+1},
>> +@dots{}, @code{SIGRTMAX} is also set aside for you to use any way you
>> +want. In addition, these signals (and no others) are guaranteed to
>> +support @dfn{real-time} signal semantics, which unfortunately this
>> +manual does not yet document.
>> +
>> +Unlike all of the other signal number macros, @code{SIGRTMIN} and
>> +@code{SIGRTMAX} are not compile-time constants, because some operating
>> +systems make the number of real-time signals tunable on a
>> +per-installation or even per-process basis. However, POSIX guarantees
>> +that there will be at least 8 signal numbers in this range.
>> +
>> +The default action for all signals in this range is to terminate the
>> +process.
>> +@end deftypevr
>> +
>> @deftypevr Macro int SIGWINCH
>> @standards{BSD, signal.h}
>> Window size change. This is generated on some systems (including GNU)
>> @@ -817,6 +838,22 @@ to print some status information about the system and what the process
>> is doing. Otherwise the default is to do nothing.
>> @end deftypevr
>>
>> +@node Internally-Used Signals
>> +@subsection Internally-Used Signals
>> +@cindex internally used signals
>
> This @cindex, however, must be underneath, as it won't be associated
> with the correct section otherwise.
Right, so I presume it is on right position, correct?
>
>> +
>> +On some operating systems, @theglibc{} needs to use a few signals from
>> +the ``true'' real-time range internally, to implement thread
>> +cancellation, cross-thread effective ID synchronization, POSIX timer
>> +management, etc. @Theglibc{} adjusts @code{SIGRTMIN} and
>> +@code{SIGRTMAX} to exclude these signals, and it also takes steps to
>> +prevent application code from altering their state: @code{sigprocmask}
>> +cannot block them and @code{sigaction} cannot redefine their handlers,
>> +for instance. Therefore, most programs do not need to know or care
>> +about these signals. We mainly document their existence for the sake
>> +of anyone who has ever wondered why there is a gap between the
>> +highest-numbered ``normal'' signal and @code{SIGRTMIN} on Linux.
>> +
>> @node Signal Messages
>> @subsection Signal Messages
>> @cindex signal messages
>
>
> Rical
>
> [1]
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Indexing-Commands.html#Indexing-Commands
>