<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Jul 2, 2022, at 2:13 PM, Jaromir Matas <mail@jaromir.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Calibri Light";
        panose-1:2 15 3 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
        {mso-style-priority:1;
        margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>


<div class="WordSection1">
<p class="MsoNormal">Hi Eliot, Marcel, all</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> This sounds right to me.  The important things would be <o:p></o:p></p>
<p class="MsoNormal">- is the activeProcess (in which the exception occurs) the UI process?  If so don’t create a new UI process.<o:p></o:p></p>
<p class="MsoNormal">- is the UI process blocked temporarily or long-term?  I’m guessing there are delays in the UI process’s stepping/rendering so some simple test for blocking might assume the UI process was blocked while in fact it was just pausing.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Yes, I realize the UI may be in a blocked state most of the time because of the intercycle pause which is not the case we need to isolate; so yes, we need some more clever test than simple #isBlocked.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Another thing is that the blocked UI will/may eventually (when signaled) become active again so if we create a new UI to deal with a subsequent error (i.e. a request to open a debugger) then this new UI should really be just “temporary”
 and should be closed when the original UI becomes active again; and this is at the moment way beyond my skills; I’m not even sure this is the right approach :)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> But I really *don’t* know what I’m talking about here.  I would talk it over with Marcel; he’s much more familiar with the code and co-located.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That would be a great help indeed :))<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Can I assume we can agree that it would be nice and reasonable if this motivation example opened the ZeroDivide without freezing the UI ?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">s := Semaphore new.<o:p></o:p></p>
<p class="MsoNormal">[1/0. s signal] fork.<o:p></o:p></p>
<p class="MsoNormal">s wait</p></div></div></blockquote><br>Yes, at least I can.  It’s a bad thing when errors in background processes don’t show up (although there is a potential issue with a flood of such events).  It’s far worse when such events cause the UI to lock up.  It would be great if the debugger clearly identified an error in a named background process (such as the finalization process) since simply closing the debugger leaves the image in a bad state.<div><br><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks!</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNoSpacing"><span lang="CS">--</span></p>
<p class="MsoNoSpacing"><strong><span style="font-family:"Calibri Light",sans-serif;color:#333333;font-weight:normal">Jaromír Matas</span></strong><span style="font-family:"Calibri Light",sans-serif;color:#555555"><o:p></o:p></span></p>
<p class="MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:#2E75B6">mail@jaromir.net</span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:eliot.miranda@gmail.com">Eliot Miranda</a><br>
<b>Sent: </b>Saturday, July 2, 2022 19:23<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">The general-purpose Squeak developers list</a><br>
<b>Subject: </b>Re: [squeak-dev] Freezing UI issue</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Jaromir,<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">On Jul 1, 2022, at 2:43 AM, Jaromir Matas <mail@jaromir.net> wrote:<o:p></o:p></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hi All,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I'd like to ask you to help me understand this: If you run the following example in the Workspace, the UI will freeze (Alt + . recoverable indeed)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">s := Semaphore new.<o:p></o:p></p>
<p class="MsoNormal">[1/0. s signal] fork.<o:p></o:p></p>
<p class="MsoNormal">s wait<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The reason is obvious - the example runs inside the UI and hence the UI will start waiting on the semaphore s. At the same time the newly forked process will try to evaluate 1/0 and will request the UI to open a debugger but this won't
 happen because the UI is waiting on a semaphore.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Now the question: Why the system won't start the debugger in a new UI? There's no 'fundamental' reason why the UI should get stuck on a semaphore instead of taking care of the new error that occurred elsewhere in the meantime. Look at 
 #spawnNewProcessIfThisIsUI: : the method tries to make sure there's a running UI so that a new debugger can be opened in case the UI is missing or is suspended. It feels like the situation where the UI *is blocked* has been left off - and I can't figure out
 whether by omission or intentionally.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I've tried to modify it like this:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">spawnNewProcessIfThisIsUI: suspendedProcess<o:p></o:p></p>
<p class="MsoNormal">                "Initialize a UI process if needed. Answer true if suspendedProcess was interrupted<o:p></o:p></p>
<p class="MsoNormal">                from a UI process."<o:p></o:p></p>
<p class="MsoNormal">                self uiProcess == suspendedProcess ifTrue: [<o:p></o:p></p>
<p class="MsoNormal">                                self spawnNewProcess.<o:p></o:p></p>
<p class="MsoNormal">                                ^true<o:p></o:p></p>
<p class="MsoNormal">                ].<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">                "Ensure that the UI process is running."<o:p></o:p></p>
<p class="MsoNormal">                self uiProcess<o:p></o:p></p>
<p class="MsoNormal">                                ifNil: [self spawnNewProcess]<o:p></o:p></p>
<p class="MsoNormal">                                ifNotNil: [:p | (p isSuspended or: [p isBlocked]) ifTrue: [     "<------- here's my change... or: [p isBlocked]"<o:p></o:p></p>
<p class="MsoNormal">                                                self restoreDisplay.<o:p></o:p></p>
<p class="MsoNormal">                                                self uiProcess resume]].<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">                ^false                    "no new process was created"<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">... and the example above no longer blocks the UI !<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I'm not saying this is a fix (I don't have any debugger/UI experience to fix it correctly); I'm just trying to demonstrate the functionality I'd like to achieve :) A real fix should maybe open a new UI instead of unblocking the existing
 one, I don't know…<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">This sounds right to me.  The important things would be <o:p></o:p></p>
<div>
<p class="MsoNormal">- is the activeProcess (in which the exception occurs) the UI process?  If so don’t create a new UI process.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- is the UI process blocked temporarily or long-term?  I’m guessing there are delays in the UI process’s stepping/rendering so some simple test for blocking might assume the UI process was blocked while in fact it was just pausing.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But I really *don’t* know what I’m talking about here.  I would talk it over with Marcel; he’s much more familiar with the code and co-located.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks very much for any input on this.<o:p></o:p></p>
<p class="MsoNormal">best,<o:p></o:p></p>
<p class="MsoNormal">Jaromir<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNoSpacing"><span lang="CS">--</span></p>
<p class="MsoNoSpacing"><strong><span style="font-family:"Calibri Light",sans-serif;color:#333333;font-weight:normal">Jaromír Matas</span></strong></p>
<p class="MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:#2E75B6">mail@jaromir.net</span></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:5.0pt;margin-left:.5in">
<o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>


<span></span><br></div></blockquote></div></body></html>