• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Missing in sigaction
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing in sigaction


  • Subject: Re: Missing in sigaction
  • From: Nat! <email@hidden>
  • Date: Wed, 28 Mar 2012 10:28:14 +0200

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.


OTOH, there is absolutely no mention of a magical 1/10 s rule in the documentation. Where did you get that from ?

Ciao
   Nat!
------------------------------------------------------
Ich selbst habe mich persönlich stets an den
sittlichen Gepflogenheiten des Philisters beteiligt;
nicht, weil ich ihnen Wert beigemessen hätte, sondern
weil ich - vorwärts, immer mal wieder! - keinen Anlaß
traf, mich von ihnen zu trennen. -- H. Mann



 _______________________________________________
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


  • Follow-Ups:
    • Re: Missing in sigaction
      • From: Tilghman Lesher <email@hidden>
References: 
 >Missing in sigaction (From: Nat! <email@hidden>)
 >Re: Missing in sigaction (From: Tilghman Lesher <email@hidden>)
 >Re: Missing in sigaction (From: Nat! <email@hidden>)
 >Re: Missing in sigaction (From: Tilghman Lesher <email@hidden>)

  • Prev by Date: Re: Missing in sigaction
  • Next by Date: Re: Missing in sigaction
  • Previous by thread: Re: Missing in sigaction
  • Next by thread: Re: Missing in sigaction
  • Index(es):
    • Date
    • Thread