speck@CIT-VAX.ARPA (07/24/84)
From: Don Speck <speck@CIT-VAX.ARPA>
Before I get any more letters misinterpreting my question, let me
clarify: nowhere did I mention ANYTHING about calling sleep() from an
interrupt routine! As you can see in my letter, I call sleep() at ipl
0x14 from rlpwrite(), the write routine for my driver. Please don't
tell me that it can't work, because a lot of 4.2bsd drivers do it; look
at lpoutput() in /sys/vaxuba/lp.c.
Perhaps I confused everybody by using the term "interrupt level"
when I should say "processor priority raised to ipl 0x14 to temporarily
lock out interrupts during a critical section". So let me rephrase the
question:
Does sleep() do anything strange when called with processor priority
at 0x14, and can signals such as SIGINT/SIGQUIT interrupt such a sleep?
Don Specklcc.bob@UCLA-LOCUS.ARPA (07/25/84)
From: Bob English <lcc.bob@UCLA-LOCUS.ARPA> No, sleep doesn't do anything strange when called at an elevated priority. Yes, signals can interrupt the sleep if the sleep priority is > PZERO. If an interrupt occurs the process will do a longjmp to whereever its longjmp structure points. Unless you have made special arrangements, this will probably pop you back into user mode with an interrupted system call. If the process has some kernel resource locked, the resource will remain locked indefinitely. --bob--