Re: Handling signals in ADA

[Robert A Duff <bobduff@world.std.com>]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:

> Someone else posted a literal translation*. The question is, what do you
> want to do? For most Ada programming, signals aren't the right tool for
> the job. Tasks and exceptions can handle many signal uses; others may
> take a little more thought to rewrite, but it's usually better to
> program in the language you're programming in, than force a design for C
> into Ada. (As a side note, SIGUSR1 is not always safe to use in an Ada
> program - GNAT in the standard (ACT) configuration uses it for
> threading.) 

I don't think using signals constitutes "a design for C".  Signals are
an operating system feature.  Many operating systems have similar
features ("per-process interrupts" or "asynchronous system traps" or
whatever).  That includes operating systems that are not so (evilly)
C-centric as Unix.

Anyway, if you want interface to signals, use a protected object with a
pragma Attach_Handler, and the various related features.  I have done
this, for example, to catch control-C interrupts -- portably to both
Unix and Windows.

> * To properly use SIGUSR1, you could write a one line C function 
> returning SIGUSR1 and import it, or write a compile time program that
> finds the value of SIGUSR1 and includes it. If you're using GNAT, you
> should check out Ada.Interrupts.Names and System.OS_Interface, which
> also tell you all the reserved signals.

You should check out Ada.Interrupts.Names even if you're *not* using
GNAT -- this package is standard (although its contents are obviously
system dependent).

- Bob