IRIX supports the following 64 signal numbers:

Signals with smaller numbers have priority for delivery. The low-numbered BSD-compatible signals, which include all kernel-produced signals, are delivered ahead of real-time signals, and signal 49 takes precedence over signal 64.

Table 5-1 is reproduced from the signal(5) reference page for convenience.

Although SIGUSR1 and SIGUSR2 are nominally defined by the you for your program's purposes, they are also used by different application packages for special signals. For example, if you set a file lock on an NFS mounted file, the NFS lock daemon may send SIGUSR1—see “NFS File Locking”.  

There are three UNIX traditions for signals, and IRIX supports all three. They differ in the library calls used, in the range of signals allowed, and in the details of signal delivery. The basic signal operations and the implementing functions are summarized in Table 5-2.(You can click on the reference pages in this table to display them.)

It is important to not mix these signal facilities. Your program should use functions from only one column of Table 5-2; otherwise unexpected results can occur.

Certain ideas are basic to the use of signals. One basic idea is that a program can block the delivery of any signal. When a signal that is sent to a program is blocked, the signal is queued and remains pending until the program unblocks the signal, or terminates. Certain urgent signals—SIGKILL, SIGSTOP, SIGCONT—cannot be blocked.

You specify which signals are blocked using a signal mask, a set of bits in which each bit corresponds to one signal number. When a bit in the mask is set on, the signal is blocked (if it is a signal that can be blocked).

Each process has a signal mask, inherited from its parent process. All three interfaces provide ways to set and clear bits in the current signal mask. The BSD interface, however, only lets you mask the first 32 signal numbers listed in Table 5-1.

Each POSIX thread has a signal mask also (see “Setting Signal Masks”). A multithreaded program (defined as a program that is linked with libpthread, so it uses the pthreads version of the standard library) should use the POSIX interface for signal handling.

You can specify one of three policies for handling an unblocked signal. You set the policy for each signal number individually.

The time that elapses from the moment a signal is generated until a signal handler begins to execute is the signal latency. Signal latency can be long (as real-time programs measure time) and signal latency has a high variability.

The IRIX kernel normally delivers a pending, unblocked signal the next time the process returns to user code from the kernel domain. In most cases, this occurs

SIGALRM, which signals the expiration of a real-time timer (see “Timer Facilities”), is given special treatment. It is delivered as soon as the kernel is ready to return to a user process after the timer interrupt, in order to preserve timer accuracy.

When a process is ready to run and is not preempted by a process of higher priority, and is executing in user code, not calling a system function, the latency for other than SIGALRM can be as much as 10 milliseconds. However, when the process is suspended (for example, waiting on a semaphore), or when there are competing processes having higher priorities, the delivery of a signal is delayed until the next time the receiving process is scheduled. This can be many milliseconds.

In general, you should use signals to deliver infrequent messages of high priority. You should not use the exchange of signals as the basis for real-time scheduling.

If you plan to handle signals asynchronously in a program that uses X intrinsics, you must take special steps. Before establishing a signal handler with the operating system, you establish one or more signal callback procedures using XtAppAddSignal(). Then, in the asynchronous signal handling function, you call XtNoticeSignal(). This function ensures that the established signal callback will be invoked like other callback functions, when it is safe to do so. This process is documented in the XtAppAddSignal(3Xt) reference page.

The only X-windows function that can safely be called from a signal handler is XtNoticeSignal().

The POSIX interface to signals is the most functionally complete and robust of the three. It is the recommended interface for all new programs. The functions used in POSIX style signal handling are summarized in Table 5-3.

In addition to the reference pages listed in Table 5-3, the following have important information about signal handling:

void name(int sig, siginfo_t *sip, ucontext_t *up)

void name(int sig, int code, struct sigcontext *sc);

The System V signal interface is compatible with code ported from UNIX System V. It includes compatibility for release 3 (SVR3) and release 4 (SVR4). Table 5-4 summarizes the functions you use to manage signals through this interface.

Only asynchronous signal handling is supported by the System V interface. Also, you must block and unblock signals individually; there is no support for setting the entire signal mask in one operation.

The semantics of SVR3-compatible signal established with signal() are not desirable for most programs. When control enters a signal handler you established using signal(), the handling of that same signal is set to default, and that signal remains unblocked. Your signal handler can use signal() to reestablish itself as the handler, or it can use sighold() to block the signal. However, even if these actions are the first statements of the handler function, there is a period of time at the beginning of the handler during which a second signal of the same type could be received. If this occurs, the second signal receives default handling and is not seen by your handler.

You can avoid this problem by using the SVR4 function sigset() instead of signal() to establish a handler. Before a handler established by sigset() is called, that signal is blocked until the handler returns, and the signal disposition is not reset to default.

The BSD signal facility is compatible with code ported from the BSD 4.2 distribution. Table 5-5 summarizes the functions you use to manage signals with this interface.

---

Note: In order to use any of the functions in Table 5-5 you must define one of the compiler variables _BSD_SIGNALS or _BSD_COMPAT prior to the inclusion of the header file signal.h. You can do this directly in the source file with #define. More commonly you will include -D_BSD_COMPAT as one of the compiler flags you define in your Makefile.

---

Only asynchronous signal handling is supported by the BSD interface. It is possible to set and interrogate the signal mask in a single operation; however, the signal mask type is the integer, so only signal numbers 1-32 can be blocked. The BSD interface does not recognize higher-numbered signals.

In many instances a program, or a process within a multiprocess program, needs to suspend execution for a period of time. IRIX contains a variety of functions that provide this capability. The functions differ in their precision and in their portability. Table 5-6 contains a summary.

Sometimes you do not want to suspend for any particular amount of time, but simply want to make the current process defer to other processes, so that any waiting processes receive a chance to run. You can achieve this in two ways. The IRIX unique function sginap() accepts an argument of 0, meaning to defer for the minimum amount of time. However, sched_yield() is a POSIX compliant function for this purpose.

The include files time.h and sys/time.h define several data types and data structures related to time. Some of these are used in POSIX time functions and others in BSD-based functions; and there are somewhat confusing similarities between them. Features of these structures are summarized in Table 5-7.

It takes time for the kernel to deliver the SIGALRM that notifies your program at the end of an interval. (The issue of signal latency in general is discussed under “Signal Latency”.) The signal latency is less for SIGALRM than for other signals, since the kernel initiates a scheduling cycle immediately after the timer interrupt, without waiting for the end of a fixed time slice. When the receiving process or thread is running or ready to run, the latency is fairly short and consistent from one signal to the next. (Even so, it is not advisable to use a repeating itimer as the time base for a real-time program). Under less favorable conditions, signal latency can be variable and sometimes lengthy (tens of milliseconds) relative to a fast timer frequency.

The IRIX kernel can be asked to implement itimers for many processes at once, each interval having a different length and starting at a different time. The kernel's method differs depending on the hardware architecture (this issue is discussed at length in the timers(5) reference page).

In earlier versions of IRIX, in order to minimize the overhead of polling for elapsed timers, the kernel did not allow normal processes to ask for timer intervals with fine granularity (sub-millisecond precision). Only processes that executed under real-time scheduling priority could ask for precise timer intervals.

Starting with IRIX 6.2, any process can request a timer interval with any precision. If this support is misused, it is possible to cause performance problems. For example, a process can set up a repeating timer at an interval so short that one CPU is monopolized by setting and handling that timer.

IRIX supports the time and timer facilities specified by IEEE standard 1003.1b-1993, commonly called POSIX timers. This timer interface is the most complete, robust, and portable, and is recommended for all new applications. The functions it includes for time measurement are summarized in Table 5-8.

The POSIX functions for interval timers are summarized in Table 5-9.

$ ptime
CLOCK_REALTIME value: sec 835660711, ns 465330000 [8.35661e+08 sec]
CLOCK_REALTIME units: sec 0, ns 10000000 [0.01 sec]
CLOCK_SGI_CYCLE value: sec 83, ns 449744360 [83.4497 sec]
CLOCK_SGI_CYCLE units: sec 0, ns 40 [4e-08 sec]
CLOCK_SGI_FAST units: sec 0, ns 1000000 [0.001 sec]

/*
|| Program to exercise POSIX clock_gettime() and clock_getres() functions.
||
||  ptime [-r -c -R -C -F]
||      -r  display CLOCK_REALTIME value
||      -R  display CLOCK_REALTIME resolution
||      -c  display CLOCK_SGI_CYCLE value
||      -C  display CLOCK_SGI_CYCLE resolution
||      -F  display CLOCK_SGI_FAST resolution (cannot get time from this)
|| Default is display everything (-rRcC).
*/
#include <time.h>
#include <unistd.h>     /* for getopt() */
#include <errno.h>      /* errno and perror */
#include <stdio.h>
void showtime(const timespec_t tm, const char *caption)
{
    printf("%s: sec %ld, ns %ld [%g sec]\n",
        caption, tm.tv_sec, tm.tv_nsec,
        ((double)tm.tv_sec) + ((double)tm.tv_nsec / 1e9));
}
main(int argc, char **argv)
{
    int opta = 1;
    int optr = 0;
    int optR = 0;
    int optc = 0;
    int optC = 0;
    int optF = 0;
    timespec_t sample, res;
    int c;
    while ( -1 != (c = getopt(argc,argv,"arRcCF")) )
    {
        switch (c)
        {
        case 'a': opta=1; break;
        case 'r': optr=1; opta=0; break;
        case 'R': optR=1; opta=0; break;
        case 'c': optc=1; opta=0; break;
        case 'C': optC=1; opta=0; break;
        case 'F': optF=1; opta=0; break;
        default: return -1;
        }
    }
    if (opta || optr)
    {
        if (!clock_gettime(CLOCK_REALTIME,&sample))
            showtime(sample,"CLOCK_REALTIME value");
        else
            perror("clock_gettime(CLOCK_REALTIME)");
    }
    if (opta || optR)
    {
        if (!clock_getres(CLOCK_REALTIME,&res))
            showtime(res,"CLOCK_REALTIME units");
        else
            perror("clock_getres(CLOCK_REALTIME)");
    }
    if (opta || optc)
    {
        if (!clock_gettime(CLOCK_SGI_CYCLE,&sample))
            showtime(sample,"CLOCK_SGI_CYCLE value");
        else
            perror("clock_gettime(CLOCK_SGI_CYCLE)");
    }
    if (opta || optC)
    {
        if (!clock_getres(CLOCK_SGI_CYCLE,&res))
            showtime(res,"CLOCK_SGI_CYCLE units");
        else
            perror("clock_getres(CLOCK_SGI_CYCLE)");
    }
    if (opta || optF)
    {
        if (!clock_getres(CLOCK_SGI_FAST,&res))
            showtime(res,"CLOCK_SGI_FAST units");
        else
            perror("clock_getres(CLOCK_SGI_FAST)");
    }
}

IRIX supports the BSD UNIX feature of interval timers or “itimers.” Table 5-10 summarizes the functions you use to manage itimers.

Each process has three itimers available to it, as summarized in Table 5-11.

The ITIMER_VIRTUAL and ITIMER_PROF have a relatively coarse precision. Their intervals vary depending on when and how often the process is dispatched. The ITIMER_REAL timer is comparable to the POSIX time base CLOCK_SGI_FAST.

In order to use an itimer, you establish a signal handler for the appropriate signal as shown in Table 5-11, then issue the setitimer() call. The principal argument to this function is a struct itimerval, an object containing two incremental time values. The it_value field specifies the time until the timer should expire. The it_interval field, when nonzero, gives the time that should be loaded into the timer after it expires.

---

Tip: One excellent reason not to mix BSD and POSIX timer support in the same program is that the POSIX struct itimerspec, used to set a POSIX timer, and the BSD struct itermval, used to set a BSD itimer, have fields with identical names, but these fields have different data types and precisions.

---

You can use setitimer() for any of three operations:

All current Silicon Graphics systems have a hardware “cycle counter,” a free-running binary counter that is incremented at a high, regular frequency. You can use the cycle counter as a high-precision timestamp.

The precision of the cycle counter is different in different system types; for example, it is a 24-bit counter in the Indy workstation, but a 64-bit counter in CHALLENGE and Onyx systems. The rate at which the timer increments is its resolution, and this also varies with the hardware type.

The cycle counter is an addressable hardware device that you can map into the address space of your process (see “Mapping Physical Memory”). When this is done you can sample the cycle counter as if it were a program variable. The code to do this mapping is discussed in the syssgi(2) reference page under SGI_QUERY_CYCLECNTR.

However, the use of the hardware cycle counter has been integrated into the POSIX timer support beginning in IRIX 6.2, and this makes access to the cycle counter much simpler than before:

The first two operations are illustrated in Example 5-1.