Re: Missing in sigaction
Re: Missing in sigaction
- Subject: Re: Missing in sigaction
- From: Tilghman Lesher <email@hidden>
- Date: Wed, 28 Mar 2012 09:43:29 -0500
On Wed, Mar 28, 2012 at 3:28 AM, Nat! <email@hidden> wrote:
> Am 28.03.2012 um 09:15 schrieb Tilghman Lesher:
>> On Tue, Mar 27, 2012 at 5:50 PM, Nat! <email@hidden> wrote:
>>> Am 27.03.2012 um 22:22 schrieb Tilghman Lesher:
>>>> On Tue, Mar 27, 2012 at 1:57 PM, Nat! <email@hidden> wrote:
>>>>> instead of many words, here's the output of two program runs once with a sleep( 2) - as in seconds, not as in man - commented in and out. What I believe this demonstrates, is that on Darwin (Kernel Version 10.8.0), blocked signal information is lost, which is incovenient. gdb has a similiar problem.
>>>>>
>>>>> Or it shows that I am misunderstanding something ;)
>>>>>
>>>>> The problem is not that the signal is occurring less often, that's expected, but that the struct __siginfo has trouble remembering things.
>>>>
>>>> You really should read the manpage for sigaction, in particular, the
>>>> section that reads:
>>>>
>>>> "In general though, signal handlers should do little more than set a
>>>> flag; most other actions are not safe."
>>>>
>>>> Note, also, that printf() is not in the list of "safe" functions to
>>>> call. Thus your call to p_log is defined as not safe. While sleep()
>>>> is safe to call, it also violates one of the cardinal rules of signal
>>>> handlers -- do only what is necessary to flag that a signal occurred,
>>>> and do not take more time than is necessary. The actual handling of
>>>> what the signal represents should be done in a main thread.
>>>
>>> Tilghman, do you really think printf will magically erase struct __siginfo.si_pid ahead of printf even being called ?
>>
>> No, I think you shouldn't be calling sleep(3) inside a signal handler.
>> Ever. Any time the execution of a signal handler lasts longer than a
>> single context switch (1/10th of a second), you are asking for
>> trouble. I also pointed out that your use of printf(3) is indicative
>> that you haven't understood the sigaction(2) documentation.
>
> It's more indicative, that you haven't really understood the code or the problem.
>
> sigaction(2) says in plain words:
>
> The following functions are either reentrant or not interruptible by sig-
> nals and are async-signal safe. Therefore applications may invoke them,
> without restriction, from signal-catching functions:
>
> Base Interfaces:
>
> ... sleep() ...
>
>
> "Therefore applications may invoke them, without restriction, from signal-catching functions"
>
> That is without restriction, even if you really feel differently.
And the next sentence is, as quoted above is:
>>>> "In general though, signal handlers should do little more than set a
>>>> flag; most other actions are not safe."
> OTOH, there is absolutely no mention of a magical 1/10 s rule in the documentation. Where did you get that from ?
1/10th of a second is the maximum amount of time each thread is given
to execute before the kernel preempts the thread, to allow another
thread (or process) to execute. It's heavily ingrained in all
Unix-based systems, a somewhat arbitrary decision made in the 1960s by
Dennis Ritchie, the father of Unix. There have been attempts by
others to modify that value, with results that caused performance to
suffer, and the takeaway is that nobody has tried to modify the
maximum timeslot since. When you wait in a signal handler longer than
the maximum length of a context switch, other processes (and not other
threads in the same process) will get multiple timeslots, but the
process in which a signal handler sleeps will be stuck, unable to do
anything else, because _nothing_ in that process other than other
signal handlers (if not blocked) can be invoked while that signal
handler is still running.
Now, for your test process, this doesn't matter all that much, because
it's not doing anything else. But it's a really bad habit to get
into, because in a real process, you will prevent every other thread
from running, including threads invoked by libraries and frameworks
designed to make the application respond in expected ways. You
_really_ need to take to heart the admonition that a signal handler
should _only_ set a flag and _immediately_ return.
-Tilghman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden