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