Re: deferred cancellation of ipc

[Marcus Brinkmann]

On Tue, Oct 14, 2003 at 05:02:17PM +0200, Niels M?ller wrote:
> Stopping the thread while figuring out what it's doing seems like the
> right thing to do. I think that's where the simplicity comes from.

I don't really see an alternative to this.  But then, I don't even know how
to safely frob another thread's local storage.
 
> For simplicity, I'd suggest that you skip the yield part, and just
> have a loop sleeping one or a few timeslices at a time. The reason
> that should work is that when we wake up either

This is merely an optimization.  If you look at the yield interface in the
specs, you see that if you have a rest on your timeslice, you can denote it
to another thread on the same cpu (in fact, the function is named
ThreadSwitch, not yield).  The idea is that in that case, we can often make
sure that the next time _we_ are scheduled, the other thread had a chance to
run and enter the ipc or leave the in_ipc block.  Even if the thread is on
another processor, it will have a chance to run while we are preempted.
If you sleep, you might sleep longer than necessary.

The counter to two is to deal with the case that the thread did run out of
his time slice almost completely, and the other thread didn't get a new
timeslice yet.

I guess there is hardly a way to predict what will happen in a real world
situation, nor does performance of this function matter as far as I am
concerned.

> One should keep that mutex locked for the entire duration of the
> cancellation function, including sleep time, right?

Yeah, I think so.  After all, the cancelled thread should only be in_ipc for
a very short time, unless it blocks on the ipc.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/