<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>I've changed the subject since I'm not sure if this is related,<br>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.  </div></div><div dir="ltr"><br></div><div dir="ltr">On Sun, 26 Aug 2018 at 05:23, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr">Hi Windows Experts,<div><br></div><div>    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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Back when I was having a go at new mutex primitives, </div><div>when a process "A" failed to lock a mutex, I wanted to return </div><div>a primitive-failed-code in addition to the usual context-change to different process "B"</div><div>However what I observed was that because of the context change </div><div>the primitive-failed-code incorrectly ended up returned on the stack of process "B".</div><div><br></div><div>I'm stretching my memory so there is a reasonable change this is misleading...</div><div>but I believe I observed this happening in CoInterpreter>>internalExecuteNewMethod  </div><div>near this code..</div><div><br></div><div>    "slowPrimitiveResponse may of course context-switch. ..."</div><div>     succeeded := self slowPrimitiveResponse.</div><div>     ...</div><div>     succeeded ifTrue: [....</div><div><br></div><div>Though I can't exactly put my finger on explaining why, my intuition is that </div><div>changing threads "half way" through a bytecode is a bad thing.   </div><div>I started (but lost my way) to develop an idea to propose... </div><div>that rather than any context-changing primitive (e.g. #primtiveWait) directly </div><div>calling CoInterpreter>>transferTo:from:,   it would just flag for #transferTo:from:</div><div>to be called at the next interpreter cycle, before the next bytecode is started.  </div><div>Thus #internalExecuteNewMethod gets to exit normally, placing any primitive-failure-code </div><div>onto the correct process stack before the context-change.  </div><div><br></div><div>Interestingly the comment in #transferTo:from says... </div><div>     "Record a process to be awoken on the next interpreter cycle."</div><div>which sounds like what I'd propose, but actually it doesn't wait for </div><div>the next interpreter cycle and instead immediately changes context.</div><div><br></div><div><div>Philosophically it seems cleaner for context changes to happen </div><div>"between" bytecodes rather than "in the middle" of them,</div><div>but I'm unclear on the practical implications.</div></div><div><br></div><div>Also, probably a year later for curiousity I was browsing the MT code</div><div>and it seemed to do something like what I'd propose, </div><div>however I can't remember that reference.</div><div><br></div><div>hope that made some sense,</div><div>cheers -ben</div></div></div>