FFI callback for interrupts in Raspberry

 

Hi Denis,

On Feb 19, 2018, at 6:35 AM, Denis Kudriashov <[hidden email]> wrote:

Hi.

I am experimenting with interrupt callbacks on Rasperry. I am using WiringPi library which allows to set the function which should be called when value of particular pin is changed.

But instead of callback execution I got following message in the console:

Warning; callback failed to own the VM

So VM is not crashed. But every interrupt produces such message.

Is it related to the fact that callback is triggered from the thread different from VM? (I not sure about such detail, just guessing)

Indeed it is.  You would need to either

- arrange that interrupts are delivered on the VM thread, e.g. by responding to the interrupt on the foreign thread by queueing the information, and using the external semaphore support to inform the image of the interrupt

- help us finish the threaded FFI so that the callback can be received from the foreign thread

- find out how a SqueakNOS VM handles receiving an interrupt at any time, or specific times (IIRC the Digitalk VM required the image to execute an enableInterrupts and a disableInterrupts bytecode around code that was executed when the VM is used n a state to take interrupts.

The thing I do not understand about SqueakNOS and responding to an interrupt at an arbitrary time is how one expects to deal with handling an interrupt during some sequence of instructions that is between suspension points, such as mid way through a store check which is adding an object to the remembered set, or mid way through a message lookup.  Does SqueakNOS actually use the enable/disable interrupts approach?

Denis, can you describe the callbacks in more detail?  What is their favorite nation? Must they be responded to immediately? 

Best regards

Denis

 

That's a perfect description. The isr handler calls signalSemaphoreWithIndex and

quietly returns. In the image there is one process waiting on each interrupt (smalltalk)

semaphore, with the smalltalk handling code for that interrupt. Of course, this only 

works for external interrupts, and not for exceptions (normally when you get a processor

exception while running smalltalk code it means something very wrong just happened, 

so you cannot just go back to it). IIRC for paging we used alienffi callbacks, but there

is a trick, you have to know a bit about the code triggering the page faults, in order to

assure that it is safe to reenter the vm.

Handling exceptions is a topic for research. But for that it is necessary to rethink in which

situations exceptions could happen. For example, could a cogvm generate a zero division

exception? If not, then a #DE might mean that the vm just crashed.

On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <[hidden email]> wrote:

Eliot,

> The thing I do not understand about SqueakNOS and responding to an interrupt
> at an arbitrary time is how one expects to deal with handling an interrupt during
> some sequence of instructions that is between suspension points, such as mid
> way through a store check which is adding an object to the remembered set, or
> mid way through a message lookup.  Does SqueakNOS actually use the
> enable/disable interrupts approach?

If I understood correctly, the only thing the VM does when it gets an
interrupt from the 8259 chips is to signal a corresponding semaphore and
immediately return to what it was doing. At some point in the future the
code waiting for the semaphore gets scheduled and then run by the VM,
but at that instant none of the problems you mention should happen. It
is that code that is resposible for telling the 8259s that the interrupt
has been handled so only then can it receive the next one.

-- Jecel

http://wiki.squeak.org/squeak/1762 (see "SqueakNOS IRQ Handling" in the
middle of this page)

--

Javier Pimás
Ciudad de Buenos Aires

 

Hi Javier,

On Tue, Feb 20, 2018 at 2:04 PM, Javier Pimás <[hidden email]> wrote:

 

That's a perfect description. The isr handler calls signalSemaphoreWithIndex and

quietly returns. In the image there is one process waiting on each interrupt (smalltalk)

semaphore, with the smalltalk handling code for that interrupt. Of course, this only 

works for external interrupts, and not for exceptions (normally when you get a processor

exception while running smalltalk code it means something very wrong just happened, 

so you cannot just go back to it). IIRC for paging we used alienffi callbacks, but there

is a trick, you have to know a bit about the code triggering the page faults, in order to

assure that it is safe to reenter the vm.

Can you say more about page faults?  Can you handle these in Smalltalk?  (I would think one can't)  Do you instead want a dedicated page fault handler?

 

Handling exceptions is a topic for research. But for that it is necessary to rethink in which

situations exceptions could happen. For example, could a cogvm generate a zero division

exception? If not, then a #DE might mean that the vm just crashed.

Well, for SqueakNOS I guess it makes sense that the VM should never generate an exception.  But if one has a Smalltalk system with an FFI then FFI calls might generate exceptions and it is /much/ nicer to catch the error and report it back, a bit like a primitive failure, rather than crashing the VM.  So I modified the VisualWorks VM to handle exceptions such as illegal instruction and bus violation and if these occurred during an FFI call (identified simply by setting and clearing a flag when in an FFI call) the handler arranged that the FFI call "failed" and the exception code was reported.

This gets more complicated when the VM is threaded.  Here one still needs to set and reset the flag when an FFI call is in progress, because the threading on FFI calls works by the heartbeat thread noticing that the VM is in an FFI call and then starting up another thread to run the VM.  So the exception handler needs to check got both the "in FFI call" flag when on the current VM thread, and for occurring in some other thread.  And if the exception happens in some other thread and that thread is known to the VM and is in fact a thread that is currently doing an FFI call then again the exception can be collected and the FFI call can "fail" and answer the exception information.

On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <[hidden email]> wrote:

Eliot,

> The thing I do not understand about SqueakNOS and responding to an interrupt
> at an arbitrary time is how one expects to deal with handling an interrupt during
> some sequence of instructions that is between suspension points, such as mid
> way through a store check which is adding an object to the remembered set, or
> mid way through a message lookup.  Does SqueakNOS actually use the
> enable/disable interrupts approach?

If I understood correctly, the only thing the VM does when it gets an
interrupt from the 8259 chips is to signal a corresponding semaphore and
immediately return to what it was doing. At some point in the future the
code waiting for the semaphore gets scheduled and then run by the VM,
but at that instant none of the problems you mention should happen. It
is that code that is resposible for telling the 8259s that the interrupt
has been handled so only then can it receive the next one.

-- Jecel

http://wiki.squeak.org/squeak/1762 (see "SqueakNOS IRQ Handling" in the
middle of this page)

--

Javier Pimás
Ciudad de Buenos Aires

--

_,,,^..^,,,_

best, Eliot