<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p>The formatting of this message was unacceptable. I'm attaching it in a reformated style ...</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div class="_rp_U4 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass" id="Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
</div>
Best,</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
Christoph<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Thiede, Christoph<br>
<b>Gesendet:</b> Montag, 8. März 2021 20:21 Uhr<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> [squeak-dev] Tackling Context>>#runUntilErrorReturnFrom: (was: BUG/REGRESSION while debugging Generator >> #nextPut:)</font>
<div> </div>
</div>
<div>Hi all, hi Eliot, hi Marcel,</div>
<div><br>
</div>
<div>it's been a long time, but this issue still exists and I have been making a lot of thoughts about it while investigating this and other issues. Marcel and I will soon release a fix for the infinite debugger chains in general, but this issue is a separate
one.</div>
<div><br>
</div>
<div><short recap> </div>
<div>Under certain circumstances, running a single step in a debugger (mostly via the Over button) abandons the current UI process and proceeds the debugged process in its place. This is caused by an
<b>insane and extremely powerful hack in Context>>#runUntilErrorReturnFrom:,</b> which hacks the context to be simulated into the currently running process. This can speed up debugging by around factor 1000. To ensure that the execution returns to the debugging
process, two guard contexts are installed on top of the respective context.</div>
<div>Unfortunately, if the debugged process contains any piece of <b>context metaprogramming,</b> i.e. by implementing coroutine logic with Context>>#swapSender:, or by performing #jumps, this can uninstall the guard contexts or make them unreachable, eventually
<b>causing the debugged process to successfully hijack the debugging process and never return control back to it.</b> </div>
<div></short recap> </div>
<div><br>
</div>
<div>After all, I think <b>there is no viable alternative to explicitly informing the debugger about such acts of context metaprogramming.</b> For this reason, I have set up a working and unpolished prototype in my image, which, in a nutshell, applies the following
changes to Context:</div>
<div><br>
</div>
<div>1. In #jump and #swapSender:, insert a send {self informDebuggerAboutContextSwitchTo: coroutine} right before installing the new sender.</div>
<div>2. #informDebuggerAboutContextSwitchTo: searches the sender stack for an UnhandledError handler that was installed by #runUntilErrorOrReturnFrom:. If it finds one, it checks whether this context would still be available after the context switch. (If yes,
nothing is done, otherwise stepping over complex messages such as {self systemNavigation allCallsOn: #foo} would become really messy.) If no, an UnhandledError is signaled to abort the #runUntilErrorOrReturnFrom: execution prematurely.</div>
<div><br>
</div>
<div>You can find the details in the attached changeset, but IMO implementation details are less relevant for the current discussion than a general understanding of the problem and the solution approach. Here are some questions for you:</div>
<div><br>
</div>
<div>1. <b>Would you agree that is the right approach to the problem</b> because there are no alternatives?</div>
<div><br>
</div>
<div>2. Now it's getting indeed a bit more technical: At the moment, #findNextRunUntilErrorOrReturnFromCalleeContextUpTo: in my implementation (horrible name, I know ...) manually traverses the chain of #nextHandlerContexts to search for an UnhandledError handler
of interest. However, I don't really like this approach because a) it creates a <b>
high coupling to the #runUntilErrorOrReturnFrom: implementation</b> (well, on the other hand, both methods resist in the same class ...) and b) it might introduce a
<b>noticeable performance drop</b> (premature benchmarks have suggested an overhead of 5%-25% depending on the task).</div>
<div>I need to build better measures, but a question in general: <b>Are we willing to accept this performance drop in order to regain correctness?</b> (In my opinion, we should be willing, it is only used for debugging and "still fast enough for our neurons"
:-))</div>
<div>An alternative to manually scanning all handler contexts could be to introduce a new exception for this (maybe ContextSwitchNotification) and let the VM do all the work. Or am I overrating "The Great VM" in this regard and things won't be able to become
faster than #handleSignal: at all? For such a low-level, performance-critical decision, I think design questions should be secondary. Do you have some thoughts and opinions about this</div>
<div><br>
</div>
<div><b>I am looking forward to your feedback! </b><span style="font-size: 12pt;">Let's get this problem solved, too, definitively before the next release! :-)</span></div>
<div><span style="font-size: 12pt;"><br>
</span></div>
<div><span style="font-size: 12pt;">Best, Christoph</span></div>
<div><br>
</div>
<div><a href="http://forum.world.st/file/t372205/runUntilErrorOrReturnFrom.cs" target="_top" rel="nofollow" style="font-size: 12pt;">runUntilErrorOrReturnFrom.cs</a></div>
<div>
<div class="signature" style="margin-top:1em; color:#666666; font-size:11px">Carpe Squeak!
</div>
<br>
<hr align="left" width="300">
Sent from the <a href="http://forum.world.st/Squeak-Dev-f45488.html">Squeak - Dev mailing list archive</a> at Nabble.com.<br>
</div>
</div>
</div>
</div>
</body>
</html>