On Tue, Apr 29, 2008 at 10:56:56AM -0700, John M McIntosh wrote:
> Ok, I was trying to make a bit more progress in building a hydra VM for 
> non-windows machines.
>
> I was going to ask about the intent of the changes in
>
> primitiveSignalAtMilliseconds
> and the removal of nextWakeupTick
>
> but then figured it out, however I'll just continue writing in case someone 
> else runs across this question.
>
> In the original code
>
> nextWakeupTick was set to the millisecond clock value when the next Delay 
> wakeup needed service.
>
> The process scheduler when it found no more work to be done would call the 
> idle process which calls
>
> ioRelinquishProcessorForMicroseconds
>
> That routine at least on the macintosh would then ask for the 
> nextWakeupTick and if it was in the
> future it would sleep until that time, or some other UI or async interrupt 
> (file/socket) occurred.
> Then wakeup and return control to the process scheduler which likely would 
> find a Delay to service
> or some sort of pending interrupt.
>
> But in the Hydra VM I see nextWakeupTick is gone and replaced with
>
>   event = WIN32_STATE(wakeUpEvent);

I asked Igor about it, and he said the intent of the new
ioWakeUp call is to do whatever it takes to abort the sleep the
VM may be in currently. This means doing dummy io with no effect
other than to abort ioRelinquishProcessorForMicroseconds.

> which I'm assuming is trying to do the same type of activity but in a more 
> windows centric manner?
> so it appears then that ioScheduleTimerSemaphoreSignalAt   passes in the 
> next wakeup time,
> then later in ioRelinquishProcessorForMicroseconds you take that data and 
> do the proper wait.

The intent was to get polling out of the VM and make it more
event driven. Maybe what that means here is that scheduling a
timer interrupt is now not part of
ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
with the old way the VM works; I've only seen the hydra way

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/