kav@ihlpa.ATT.COM (Vangness) (07/11/88)
Should a process that is suspended doing a read on a pipe be able to field a signal that it has set a signal handler for? We are working on a project (At Illinois Institute of Technology) where a parent process forks off a child and communicates with the child via pipes (pipe(2) type pipes). The child process sets up a few signal handlers (SIGALRM and SIGIOT) and does a read on the pipe. Since there is nothing to read, the child is suspended. Along comes a SIGIOT (from a LAN device driver that wants to notify the process that a incoming frame has arrived) and sure enough, an F1 reveals that the IP now contains the address of the signal handler function (_begsig) but the process is never unsuspended so it just sits there. The signal handler would normally reset the signal handler for the signal, but since it never ran, the next SIGIOT causes a core dump and termination. Also, alarm and SIGALRM type processing appears to produce the same results. Looking through the code for do_unpause in fs/pipe.c, it looks like this is the desired action. At line 10591 (in the book) only processes suspended on tty i/o are unsuspended. As a temporary fix, I have included the following at line 10603 (the books line number again) } else { reply(proc_nr, EINTR); } Was this the designed behavior of pipes and signals in Minix? Is this a reasonable solution? I am running 1.2 using Turbo C as a development environment. Thanks, Kurt Vangsness AT&T Bell Laboratories - Naperville, Ill att!att-ih!ihlpa!kav