Hi Andreas,

On Tue, Apr 28, 2009 at 8:33 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Igor Stasenko wrote:
>
>> I came to an idea , you might be interested in.
>> As many of us know, some CPUs having a special mode - interrupt mode.
>> What if we introduce the interrupt mode for scheduler?
>>
> [... snip ...]
>
>> Now i trying to imagine, how a basic stuff might look like(please
>> correct me if its utterly wrong way ;), if we will be able to use
>> interrupt mode.
>>
>
> This is actually along similar lines of thought that I had when I was
> thinking of how to get rid of the builtin VM scheduling behavior. The main
> thought that I had was that the VM may have a "special" process - the
> scheduler process (duh!) which it runs when it doesn't know what else to do.
> The VM would then not directly schedule processes after semaphore signals
> but rather put them onto a "ready" queue that can be read by the scheduler
> process and switch to the scheduler process. The scheduler process decides
> what to run next and resumes the process via a primitive. Whenever an
> external signal comes in, the VM automatically activates the scheduler
> process and the scheduler process then decides whether to resume the
> previously running process or to switch to a different process.
>
> In a way this folds the timer process into the scheduler (which makes good
> sense from my perspective because much of the work in the timer is stuff
> that could be more effectively take place in the scheduler). The
> implementation should be relatively straightforward - just add a scheduler
> process and a ready list to the special objects, and wherever the VM would
> normally process switch you just switch to the scheduler. Voila, there is
> your user-manipulable scheduler ;-) And obviously, anything that is run out
> of the scheduler process is by definition non-interruptable because there is
> simply nothing to switch to!


How would you generalise this to a natively multi-threaded VM?  Obviously
one simple way is to stop the other processors at a suspension point before
letting the scheduler process proceed, but is there anything cleverer that
doesn't halt all processors until the singleton scheduler has made its mind
up?


> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090428/499fd0b2/attachment.htm