Signals

An application program can request to be notified asynchronously (request that the system send a signal) when a condition that the application is interested in occurs.

There are two asynchronous signals that sockets send to an application.

SIGURG is a signal that is sent when out-of-band (OOB) data is received on a socket for which the concept of OOB data is supported. For example, a socket with an address family of AF_INET and a type of SOCK_STREAM can be conditioned to send a SIGURG signal.
SIGIO is a signal that is sent when normal data, OOB data, error conditions, or just about anything happens on any type of socket.

The application should ensure that it is able to handle receiving a signal before it requests the system to send signals. This is done by setting up signal handlers. One way to set a signal handler is by issuing the sigaction() call.

An application requests the system to send the SIGURG signal by one of the following methods:

Issuing a fcntl() call and specifying a process ID or a process group ID with the F_SETOWN command.
Issuing an ioctl() call and specifying the FIOSETOWN or the SIOCSPGRP command (request).

An application requests the system to send the SIGIO signal in two steps. First it must set the process ID or the process group ID as previously described for the SIGURG signal. This is to inform the system of where the application wants the signal to be delivered. Second, the application must do either of the following tasks:

Issue the fcntl() call and specify the F_SETFL command with the FASYNC flag.
Issue the ioctl() call and specify the FIOASYNC command.

This step requests the system to generate the SIGIO signal. Note that these steps can be done in any order. Also note that if an application issues these requests on a listening socket, the values set by the requests are inherited by all sockets that are returned to the application from the accept() function. That is, newly accepted sockets also have the same process ID or process group ID as well as the same information with regard to sending the SIGIO signal.

A socket can also generate synchronous signals on error conditions. Whenever an application receives [EPIPE] an errno on a socket function, a SIGPIPE signal is delivered to the process that issued the operation receiving the errno value. On a Berkeley Socket Distribution (BSD) implementation, by default the SIGPIPE signal ends the process that received the errno value. To remain compatible with previous releases of the i5/OS™ implementation, the i5/OS implementation uses a default behavior of ignoring for the SIGPIPE signal. This ensures that existing applications are not negatively affected by the addition of the signals function.

When a signal is delivered to a process that is blocked on a sockets function, the function returns from the wait with the [EINTR] errno value, allowing the application's signal handler to run. The functions for which this occur are:

accept()
connect()
poll()
read()
readv()
recv()
recvfrom()
recvmsg()
select()
send()
sendto()
sendmsg()
write()
writev()

It is important to note that signals do not provide the application program with a socket descriptor that identifies where the condition being signalled actually exists. Thus, if the application program is using multiple socket descriptors, it must either poll the descriptors or use the select() call to determine why the signal was received.