[Vm-dev] context change versus primitive failure return value (was: FFI exception failure support on Win64 (Win32 also?))

[Ben Coman]

I've changed the subject since I'm not sure if this is related,
but the description dredged up a memory of a concern I had a while ago
regarding the interaction of context-switching and
primitive-failure-return-values.

On Sun, 26 Aug 2018 at 05:23, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> Hi Windows Experts,
>
>     I'm trying to have the FFI exception failure support work across the
> board.  What I see now is that the 64-bit StackVM works, while the 64-bit
> CogVM does not, even though they have exactly the same exception handling
> machinery in place (the new squeakExceptionHandler machinery; thank you
> whoever wrote it, it looks very nice), and the same essential architecture
> for jumping back into the interpreter.
>
> I expect the issue is that the machinery for maintaining a chain through
> the stack and/or the stack search used in exception delivery is broken my
> careless management of the C stack in the Cog VM, whereas in the StackVM
> the C stack remains undisturbed.
>

Back when I was having a go at new mutex primitives,
when a process "A" failed to lock a mutex, I wanted to return
a primitive-failed-code in addition to the usual context-change to
different process "B"
However what I observed was that because of the context change
the primitive-failed-code incorrectly ended up returned on the stack of
process "B".

I'm stretching my memory so there is a reasonable change this is
misleading...
but I believe I observed this happening in
CoInterpreter>>internalExecuteNewMethod
near this code..

    "slowPrimitiveResponse may of course context-switch. ..."
     succeeded := self slowPrimitiveResponse.
     ...
     succeeded ifTrue: [....

Though I can't exactly put my finger on explaining why, my intuition is
that
changing threads "half way" through a bytecode is a bad thing.
I started (but lost my way) to develop an idea to propose...
that rather than any context-changing primitive (e.g. #primtiveWait)
directly
calling CoInterpreter>>transferTo:from:,   it would just flag for
#transferTo:from:
to be called at the next interpreter cycle, before the next bytecode is
started.
Thus #internalExecuteNewMethod gets to exit normally, placing any
primitive-failure-code
onto the correct process stack before the context-change.

Interestingly the comment in #transferTo:from says...
     "Record a process to be awoken on the next interpreter cycle."
which sounds like what I'd propose, but actually it doesn't wait for
the next interpreter cycle and instead immediately changes context.

Philosophically it seems cleaner for context changes to happen
"between" bytecodes rather than "in the middle" of them,
but I'm unclear on the practical implications.

Also, probably a year later for curiousity I was browsing the MT code
and it seemed to do something like what I'd propose,
however I can't remember that reference.

hope that made some sense,
cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180828/ac6dc42d/attachment.html>