<div dir="ltr">That's a perfect description. The isr handler calls signalSemaphoreWithIndex and<div>quietly returns. In the image there is one process waiting on each interrupt (smalltalk)</div><div>semaphore, with the smalltalk handling code for that interrupt. Of course, this only </div><div>works for external interrupts, and not for exceptions (normally when you get a processor</div><div>exception while running smalltalk code it means something very wrong just happened, </div><div>so you cannot just go back to it). IIRC for paging we used alienffi callbacks, but there</div><div>is a trick, you have to know a bit about the code triggering the page faults, in order to</div><div>assure that it is safe to reenter the vm.</div><div><br></div><div>Handling exceptions is a topic for research. But for that it is necessary to rethink in which</div><div>situations exceptions could happen. For example, could a cogvm generate a zero division</div><div>exception? If not, then a #DE might mean that the vm just crashed.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <span dir="ltr"><<a href="mailto:jecel@merlintec.com" target="_blank">jecel@merlintec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Eliot,<br>
<br>
> The thing I do not understand about SqueakNOS and responding to an interrupt<br>
> at an arbitrary time is how one expects to deal with handling an interrupt during<br>
> some sequence of instructions that is between suspension points, such as mid<br>
> way through a store check which is adding an object to the remembered set, or<br>
> mid way through a message lookup.  Does SqueakNOS actually use the<br>
> enable/disable interrupts approach?<br>
<br>
If I understood correctly, the only thing the VM does when it gets an<br>
interrupt from the 8259 chips is to signal a corresponding semaphore and<br>
immediately return to what it was doing. At some point in the future the<br>
code waiting for the semaphore gets scheduled and then run by the VM,<br>
but at that instant none of the problems you mention should happen. It<br>
is that code that is resposible for telling the 8259s that the interrupt<br>
has been handled so only then can it receive the next one.<br>
<br>
-- Jecel<br>
<br>
<a href="http://wiki.squeak.org/squeak/1762" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/<wbr>1762</a> (see "SqueakNOS IRQ Handling" in the<br>
middle of this page)<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Javier Pimás<br>Ciudad de Buenos Aires</div></div>
</div>