sleep (), PCATCH, and ptrace
Joel Clark
joel at intelisc.UUCP
Thu May 19 10:47:24 AEST 1988
I was very interested in the recent disscussion of sleep(), PCATCH
and interrupts. In brief:
1) sleep(addr,j) with j < PZERO is uninterruptable.
2) sleep(addr,j) with j > PZERO is interruptable with the sleep
immediately executing "longjmp(u.u_qsav);". The user would
have an errno value EINTR for "interrupted system call", but
would continue executing.
3) sleep(addr,j) with j > PZERO and j | PCATCH is interruptable and
when interrupted will return 1 to the calling process. This
allows the calling process to "cleanup (kernal data)" and
execute its own "longjmp(u.u_qsav)".
Right so far??
Questions:
In #3 above what are the consequences of replacing the longjmp
with a return?
If the process in #2 or #3 above is running under a debugger,
and the user types an interrupt (DEL, ^C, whatever), and then
continues, and the debugger trys to continue the process by
using ptrace(7, , ,0);, why is the sleep interrupted?
ptrace(7, , ,0) is supposed to continue the process with all
pending signals deleted.
An example of this is to run sdb on the following program:
########################################################################
#include <fcntl.h>
main()
{
int fd,n;
char buf[100];
fd = open("/dev/tty",O_RDWR);
perror("sleep");
n = read(fd,buf,10);
perror("sleep2");
printf("Buf = %s\n",buf);
}
##########################################################################
After the first sleep message hit DEL. The read system call will return
with a "Interrupted system call" message.
Though I cannot be sure that sdb is continuing with the 4th argument = 0,
the debugger I am having problems with is not sdb, and I am sure it is
using "ptrace(7, , ,0);"
I am using System V R3.0 for the 80386 as supplied by ATT.
Joel Clark
Intel Scientific Computers joel at intelisc.uucp.com
Beaverton, OR 97006 USA {tektronix}!ogcvax!intelisc!joel
(503) 629-7732
Intel Scientific accepts no liabilities from my statements here.
More information about the Comp.unix.wizards
mailing list