[Vm-dev] Cog: A question about: setInterruptCheckChain()

[Eliot Miranda]

Hi Igor,

On Tue, Sep 28, 2010 at 10:48 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> As far as i understood , this is a way to insert own
> function to force VM to interrupt.
>

Alas I think it's the reverse of this.  It is a way of getting the VM's
heartbeat to interrupt other functions.  In both Cog VMs there is a
heartbeat (preferrably in a high-priroity thread) that interrupts the VM at
approximately 1KHz.  It does this by setting the VM's stackLimit to a value
that will cause the next stack check to always fail (stacks grow down so
(unsigned)-1 is the value).  Then the VM checks for events as part of its
stack overflow processing.  This makes the stack check do double-duty, and
avoids having to maintain a counter which (a) is slow due to a
read-modify-write cycle and (b) runs at a variable rate because the rate at
which the counter counts depends on what the VM is doing.  However, the
heartbeat depends on the VM performing frequent stack checks (which it does
on non-primiive sends) which won't help if for example the VM is executing a
long-running primitive.

The Bochs plugin executes x86 code generated by the Cog JIT when simulating
the Cog VM.  Bochs would happily run forever if the Cog JIT generated code
that looped and I'd be hosed, except that setInterruptCheckChain allows the
Bochs plugin to stop running when it is interrupted.  So this isn't even
close to what you want, right?



> This is cool.
>
> But i don't see another insertion point, which could make this feature
> complete.
> Suppose my plugin needs to handle some external events.
> Then, in my custom interrupt checker i can check if there any pending
> events to handle, while
> during interrupt i should be able to install own routine as well,
> which could actually handle
> events (like convert events to some object(s) and/or signal semaphore etc)
> without worrying that i'm doing this in the middle of interpreter
> cycle, which may
> damage interpreter's volatile state.
>

Well, the signalExternalSemaphore mechanism (at least in Cog) is thread-safe
and can be used at any time form any thread to request a signal that will
get performed at the next event check.

The threaded FFI I'm working on will allow one to attempt a callback at any
time.  The callback will simply block until it is safe for it to take over
the VM.  So this will also be thread-safe.  But its not one yet.

HTH
Eliot


P.S. I saw your other messages and will try and respond tomorrow.



>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100928/cf3f31cd/attachment.htm