[squeak-dev] Freezing UI issue

Marcel Taeumel marcel.taeumel at hpi.de
Sun Jul 3 09:22:21 UTC 2022


Hi all --

I did a small spike via Morphic-mt.2016 (Inbox).

Not sure whether this issue is actually relevant in Morphic applications. CMD+Dot will help you anyway. What would be the reason for such a strange "semaphore wait" in the UI process other than what the framework does anyway?

Best,
Marcel
Am 03.07.2022 01:13:27 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 2, 2022, at 2:13 PM, Jaromir Matas <mail at jaromir.net> wrote:



Hi Eliot, Marcel, all
 
> This sounds right to me.  The important things would be 
- is the activeProcess (in which the exception occurs) the UI process?  If so don’t create a new UI process.
- 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.
 
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.
 
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 :)
 
> 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.
 
That would be a great help indeed :))
 
Can I assume we can agree that it would be nice and reasonable if this motivation example opened the ZeroDivide without freezing the UI ?
 
s := Semaphore new.
[1/0. s signal] fork.
s wait

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.

 
Thanks!
 
--
Jaromír Matas
mail at jaromir.net
 
From: Eliot Miranda [mailto:eliot.miranda at gmail.com]
Sent: Saturday, July 2, 2022 19:23
To: The general-purpose Squeak developers list [mailto:squeak-dev at lists.squeakfoundation.org]
Subject: Re: [squeak-dev] Freezing UI issue
 
Hi Jaromir,


On Jul 1, 2022, at 2:43 AM, Jaromir Matas <mail at jaromir.net> wrote:

Hi All,
 
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)
 
s := Semaphore new.
[1/0. s signal] fork.
s wait
 
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.
 
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.
 
I've tried to modify it like this:
 
spawnNewProcessIfThisIsUI: suspendedProcess
                "Initialize a UI process if needed. Answer true if suspendedProcess was interrupted
                from a UI process."
                self uiProcess == suspendedProcess ifTrue: [
                                self spawnNewProcess.
                                ^true
                ].
 
                "Ensure that the UI process is running."
                self uiProcess
                                ifNil: [self spawnNewProcess]
                                ifNotNil: [:p | (p isSuspended or: [p isBlocked]) ifTrue: [     "<------- here's my change... or: [p isBlocked]"
                                                self restoreDisplay.
                                                self uiProcess resume]].
 
                ^false                    "no new process was created"
 
... and the example above no longer blocks the UI !
 
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…
 
This sounds right to me.  The important things would be 
- is the activeProcess (in which the exception occurs) the UI process?  If so don’t create a new UI process.
- 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.
 
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.
 


 
Thanks very much for any input on this.
best,
Jaromir
 
--
Jaromír Matas
mail at jaromir.net
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220703/7369c44a/attachment.html>


More information about the Squeak-dev mailing list