Example 20-4. The ntfy_pipe.c program (continued)
if (!*++argv)
puts("specify a program [w/args]"), exit(1);
pipe(pipe_io[0 ]); /* set up input pipe */
pipe(pipe_io[1 ]); /* set up output pipe */
switch (pid = fork()) {
case -1:
perror("fork failed");
case 0: /* child */
/* redirect childs stdin (0), stdout (1) and stderr(2) */
dup2(pipe_io[0 ][0 ], 0);
dup2(pipe_io[1 ][1 ], 1);
dup2(pipe_io[1 ][1 ], 2);
for (i = getdtablesize(); i > 2; i--)
(void) close(i);
for (i = 0; i < NSIG; i++)
(void) signal(i, SIG_DFL);
execvp(*argv, argv);
if (errno == ENOENT)
printf("%s: command not found.0, *argv);
default: /* parent */
close(pipe_io[0][0]); /* close unused portions of pipes */
/* when the process outputs data, read it */
notify_set_input_func(client1, read_it, pipe_io[1 ][0]);
notify_set_wait3_func(client1, sigchldcatcher, pid);
/* wait for user input -- then write data to pipe */
notify_set_input_func(client2, write_it, 0);
notify_set_wait3_func(client2, sigchldcatcher, pid);
* callback routine for when there is data on the parents stdin to
* read. Read it and then write the data to the child process via
* the pipe.
write_it(client, fd)
Notify_client client;
int fd;
484 XView Programming Manual
Example 20-4. The ntfy_pipe.c program (continued)
char buf[BUFSIZ];
int bytes, i;
/* only write to pipe (childs stdin) if user typed anything */
if (ioctl(fd, FIONREAD, &bytes) == -1 || bytes == 0) {
notify_set_input_func(client, NOTIFY_FUNC_NULL, pipe_io[0 ][1 ]);
} else
while (bytes > 0) {
if ((i = read(fd, buf, sizeof buf)) > 0) {
printf("[Sending %d bytes to pipe (fd=%d)]0,
i, pipe_io[0 ][1 ]);
write(pipe_io[0][1], buf, i);
} else if (i == -1)
bytes -= i;
* callback routine for when there is data on the childs stdout to
* read. Read, then write the data to stdout (owned by the parent).
read_it(client, fd)
Notify_client client;
register int fd;
char buf[BUFSIZ];
int bytes, i;
if (ioctl(fd, FIONREAD, &bytes) == 0)
while (bytes > 0) {
if ((i = read(fd, buf, sizeof buf)) > 0) {
printf("[Reading %d bytes from pipe (fd=%d)]0,
i, fd);
(void) write(1, buf, i);
bytes -= i;
* handle the death of the child. If the process dies, the child
* dies and generates a SIGCHLD signal. Capture it and disable the
* functions that talk to the pipes.
sigchldcatcher(client, pid, status, rusage)
Notify_client client; /* the client noted in main() */
int pid; /* the pid that died */
union wait *status; /* the status of the process (unused here) */
struct rusage *rusage; /* resources used by this process (unused) */
The Notifier 485
Example 20-4. The ntfy_pipe.c program (continued)
if (WIFEXITED(*status)) {
printf("Process termined with status %d0, status>w_retcode);
/* unregister input func with appropriate file descriptor */
notify_set_input_func(client, NOTIFY_FUNC_NULL,
(client == client1)? pipe_io[1][0] : 0);
puts("SIGCHLD not handled");
Assuming that the program was run with cat (1) as described earlier, input to the child pro-
cess comes from the function write_it(). That is, write_it() is the function that
writes to the other side of the pipe that the child is reading from. This function was set up as
the input_func for the parent’s stdin. The function gets its input from whatever you type in
the window in which you ran the program. It could have gotten its input from a text panel
item or a selection using the selection service. It reads whatever data is sent through the pipe
and ends up as the stdin for the child process.
Similarly, when the child process writes anything to its stdout, the data is redirected
through the pipe. The parent reads from the other end of the pipe in read_it(). Whatever
the parent reads is written to the parent’s stdout, which is the user’s tty window. It does
this by calling write(1, buf, i). This line of the program can easily be replaced by:
textsw_insert(textsw, buf, i);
This shows how you can redirect the output (including stderr output) from a child process
to a text subwindow.
The last thing to note about the program is its treatment of extraneous file descriptors and of
signals handled by the child process after forking. When using fork(), the child process
inherits all the file descriptors and signal handling set up by the parent.* This could seriously
affect your program if the child process gets certain signals. In this case the best thing for the
child to do is loop through all the signals that are dealt with by the parent and reset them to
SIG_DFL using signal (3). Then it can close all file descriptors except for the child’s
stdin (0), stdout (1), and stderr (2) descriptors.
We use the signal() system call here because it is assumed that the child is not going to
execute any of the XView code in the parent’s program. Therefore, the child does not need
to use the notify_set_signal_func() routine to unregister the signals. Releasing
these signals in this way completely disassociates the program from the parent.
This very general program is used as an example, but it is useful in all applications that need
to run external processes. The only modifications it needs are alternate sources for the input
and output of the parent. main() could be replaced by a general function that simply gets
an argv parameter containing the program to execute, including arguments.
*Unless the file descriptors were set to close on exec using ioctl(fd, FIOCLEX, 0).
486 XView Programming Manual
The program could be modified to be used as a replacement for the system (3) call. Even if
you do not expect to read the child’s stdout or send data to its stdin, the child process still
needs to be handled differently from system (3) because that function calls wait() and
attempts to do its own signal handling.
20.8.3 Exception Occurred Events
Exception occurred notifications are similar to input pending notifications. The only known
devices that generate exceptions are stream-based socket connections when an out-of-band
byte is available. Thus a SIGURG signal catcher is set up by the Notifier, much like a SIGIO
for asynchronous input.
notify_set_exception_func(nclient, func, fd)
Notify_client nclient;
Notify_func func;
int fd;
20.8.4 Getting an Event Handler
This section contains a list of the notify_get_*_func() routines. These functions
allow you to retrieve the value of a client’s event handler. Once you have the value of a
client’s event handler, you could modify or replace the event handler. It is recommended that
you use the Notifier’s interposition mechanism instead of using these functions. The argu-
ments for these functions parallel the associated notify_set_*_func() functions
described previously, except for the absence of the event handler function pointer. Refer to
the XView Reference Manual for a description of the arguments.
For all of the notify_get_*_func() functions in the following list, a return value of
NOTIFY_FUNC_NULL indicates an error. If the client is unknown, then notify_errno is
set to NOTIFY_UKNOWN_CLIENT. If no event handler is registered for the specified event,
then notify_errno is set to NOTIFY_NO_CONDITION. Other values on notify_errno
are possible, depending on the event; for example, NOTIFY_BAD_FD if an invalid file descrip-
tor is specified.
Here is a list of the event handler retrieval routines:
notify_get_input_func(client, fd)
notify_get_event_func(client, when)
notify_get_output_func(client, fd)
notify_get_exception_func(client, fd)
notify_get_signal_func(client, which)
notify_get_itimer_func(client, signal, mode)
The Notifier 487
notify_get_wait3_func(client, pid)
20.9 Interposition
The Notifier provides a mechanism called interposition, with which you can intercept control
of the internal communications within XView. Interposition is a powerful way to both moni-
tor and modify window behavior in ways that extend the functionality of a window object.
Interposition allows a client to intercept an event before it reaches the base event handler.
The base event handler is the one set originally by a client. The client can call the base event
handler before and/or after its own handling of the event or not at all. This allows the appli-
cation to override the handling provided by XView’s base event handler, or to add special
event handling. The notifier supports interposition by keeping track of how interposition
functions are ordered for each type of event for each client.
There may be more than one interposer for a Notifier client. As each interposer is added, it is
inserted ahead of the last interposer installed. Interposes may also be removed from the
interposer list. When an event arrives, the Notifier calls the function at the top of the inter-
poser list for that client.
Keeping track of which function to call when running down the list of interposers is done by
maintaining an interposition stack. The number of interpositions allowed on the stack is lim-
ited to a maximum size (about six levels deep). Since the base event handler is placed on the
interposition stack, there are five usable levels, although few applications should require
more than two levels of interposition. Figure 20-2 illustrates the flow of control with interpo-
sition. Note that the interposer could have stopped the flow of control to the next event han-
Interposer Base Event Handler
Figure 20-2. Flow of control in interposition
488 XView Programming Manual

Get Volume 7A: XView Programming Manual now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.