Re: What can a signal handler do with SIGSTKSZ?

[Carlos O'Donell <carlos at redhat dot com>]

On 1/11/19 2:02 PM, Szabolcs Nagy wrote:
> On 11/01/2019 17:44, Carlos O'Donell wrote:
>> In the continuing series of "What can X do with Y?" [1]
>>
>> I would like to get consensus on what a signal handler can do with
>> SIGSTKSZ amount of space.
>>
>> I propose the following:
>> ~~~
>> The implementation only guarantees that a signal handler can
>> manipulate a reasonable amount of local variables (no more than
>> 2 KiB worth), and can read and write to memory, carry out atomic
>> operations, and call simple C library functions that do similar
>> memory and simple string operations e.g. memcpy, memset, strcmp,
>> strcpy. The amount of signal stack allocated for SIGSTKSZ is not
>> sufficient to call complex signal-safe functions e.g. fork, _exit,
>> abort, nor any that can be canceled (requires enough stack for
>> cancellation). Any other operations or function calls in the
>> signal handler should be evaluated for runtime stack usage and
>> additional stack beyond SIGSTKSZ should be allocated.
>> ~~~
>>
>> Thoughts?
> 
> instead of "local variables" i'd say: user
> code may use X bytes stack space and the
> rest is for the runtime (which is guaranteed
> to be enough for simple libc calls,...).
> 
> X can be 2048.
> 
> runtime stack usage vs user stack usage can
> be accounted based on stack usage of libc code
> vs user code.
 
I was wondering if I could simplify the language and just say:

There are (SIGSTKSZ - MINSTKSZ) bytes to use upon entry to the
first signal handler, with stack space consumption happening
as the handler executes. Each subsequent nested signal handler
uses an additional MINSTKSZ bytes. 

What do you think?

-- 
Cheers,
Carlos.