[squeak-dev] Freezing UI issue
Eliot Miranda
eliot.miranda at gmail.com
Sat Jul 2 17:23:16 UTC 2022
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/20220702/2bd9e6cb/attachment.html>
More information about the Squeak-dev
mailing list
|