Help with 4.3 mod to kill uninteruptable procs.

[Y. Rock Lee]

In article <5558 at awdprime.UUCP> jfh at greenber.austin.ibm.com (John F Haugh II) writes:
>In article <1991Feb21.152845.29019 at cbnews.att.com> rock at cbnews.att.com (Y. Rock Lee) writes:
>>Yes, the process will think it has the resource it was sleeping on.
>>But, it will be killed and release the resource during its exit
>>before it has a chance to "think". This part looks OK to me.
>
>A typical sleep loop looks something like
>
>	while (some_status & some_busy_flag)
>		sleep (&some_status, PRI_O_MINE);
>
>	some_status |= some_busy_flag;

This was what I had in mind (which was wrong after I double checked it):

	A signal puts this sleeping process back into the run queue (its 
	priority has been set to higher than PZERO). sleep doesn't return;
	it does a longjmp back to syscall. Before the system call returns,
	it checks if there is a signal. There is. So, it handles the signal
	and exits (no signal handling routine set).

The catch is that the process went to sleep before we change its priority.
In this case sleep goes different route and does a simple return. 
Therefore, we will continue execute the driver code, which may be dangerous!

>What is needed is an exception routine that understands =exactly=
>what to do to reset the resource to some well-defined state for any
>possible state the resource may be in.

That's the reason why system priority is chosen to begin with.
So, don't mess with it IF you can convince your professor not to do 
this project, :-)  But, I guess, it is OK to do "experiment" in school.

On the other hand, this utility can be very useful. If a process is hanging 
but cannot be killed (sleeping in uninterruptable priority), you have two
ways to get rid of it: use this utility or reboot the system. That is,
this utility can be useful, but is DANGEROUS in general!


Y. Rock Lee, att!cblph!rock
             rock at cblph.ATT.COM