There is also the Project>>primitiveError: if the UI process get in trouble

Best,
Karl

On Sat, Jul 2, 2022 at 11: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
>
>
>
> Thanks!
>
>
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>
>
> *From: *Eliot Miranda <eliot.miranda at gmail.com>
> *Sent: *Saturday, July 2, 2022 19:23
> *To: *The general-purpose Squeak developers list
> <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/20220702/6dd6a90d/attachment.html>