Re: How doess Cocoa handle SIGINT?
Re: How doess Cocoa handle SIGINT?
- Subject: Re: How doess Cocoa handle SIGINT?
- From: Douglas Davidson <email@hidden>
- Date: Tue, 26 Jun 2001 09:34:31 -0700
On Monday, June 25, 2001, at 05:05 PM, Thierry Faucounau wrote:
>
I have some questions relating to the handling of SIGINT from a Cocoa
>
app.
>
>
Does the Cocoa runloop handle signals for you? Or is it OK (in fact
>
required) to put in my own signal handler?
Cocoa has a general policy of avoiding the use of signals. You may use
them yourself for whatever purposes you require, but you should keep in
mind that very little is safe from within the context of a signal
handler. In particular, there is no guarantee that any Cocoa APIs can
be safely called from within a signal handler.
There are many other ways--AppleEvents, for example--to send
notifications to Cocoa applications in such a way that they will be
processed within the normal context of the run loop. There are
situations in which externally-generated asynchronous signals are
appropriate--for example, if you are writing a server daemon, then Unix
convention suggests the use of certain signals--but in general they are
not the best means of communicating with a Cocoa application.
>
Does hitting Control-C on the keyboard send a SIGINT to the frontmost
>
Cocoa app?
No; this is a shell convention, not related to the GUI. Hitting
control-C on the keyboard sends a key-down event to the active Cocoa
application, with the character 'c' and the control modifier. If
Terminal happens to be the active application, then I believe that
hitting control-C will send a SIGINT to the current foreground process
in the current key window. If you launch a Cocoa application from a
shell (as you certainly may) then you can interrupt it in this way.
However, in general, most Cocoa applications are launched by other
means, and you will need to signal them by pid.
Douglas Davidson