Path: utzoo!attcan!uunet!littlei!intelisc!joel
From: joel@intelisc.UUCP (Joel Clark)
Newsgroups: comp.unix.wizards
Subject: sleep (), PCATCH, and ptrace
Keywords: sleep, PCATCH ptrace
Message-ID: <268@intelisc.UUCP>
Date: 19 May 88 00:47:24 GMT
Organization: Intel Scientific Computers, Beaverton, OR
Lines: 64

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@intelisc.uucp.com
Beaverton, OR  97006  USA		{tektronix}!ogcvax!intelisc!joel
(503) 629-7732

Intel Scientific accepts no liabilities from my statements here.