An analysis of interrupt behavior (was: Re: 6293LowSpaceWatcherFix-dtl considered harmful)

Tim Rowledge tim at sumeru.stanford.edu
Fri Apr 1 06:50:14 UTC 2005


Andreas Raab <andreas.raab at gmx.de> wrote:

> Yes. Easily so. The "major safeguard" that Tim referred to is actually a
Not me so far as I can tell...

> If this is really the problem, then the only true solution I can see is 
> to modify the VM so that we have enough information available to figure 
> out what the preempted process was at the time that particular signal 
> (user interrupt or low space) happened[***]. Note that the information 
> might be indirect - if, for example, we could measure how long a process 
> was running *without* giving up control to a lower priority process 
> (e.g., actively yielding or waiting on a semaphore) this should already 
> be enough to identify the "right" guy to interrupt.

Well we know the active context of course and for a little more work we know
the active process, so the info is there.
The amusing part is that the semaphore used for low space has the lowspace
process on its list and we remove it as part of signalling. Maybe if we stuck
the active process on the end as some 'helpful context' it would make life
simpler. Or a subclass of Semaphore with a more explicit ivar(s) if we want to
reduce confusion potential.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
The colder the X-ray table, the more of your body is required on it.



More information about the Squeak-dev mailing list