[Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

[Juan Vuletich]

Hi Jaromir,

On 8/1/2022 9:38 AM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> In our previous discussion we discussed a few examples:
>
> [1/0] fork.
>
> [ 10000 factorial. 5 seconds asDelay wait ] repeat
>
> This one represents a situation where the UI is blocked and we (mostly 
> you indeed) modified the code to create a new UI to open the debugger 
> for the [1/0] process request while the old UI is idly waiting.
>

Right.

>
> [1/0] fork.
>
> [ 10000 factorial. Processor yield ] repeat
>
> This one represents a different situation where, again, the [1/0] 
> process starts executing but the debug request gets stuck (deferred) 
> in the UI process because the UI process is "busy" executing its 
> Workspace task.
>
> We concluded that this looks like a more complex scenario than the 
> "blocked UI" scenario presented above.
>

My thought was that 'you asked your UI process to be busy, so you don't 
get UI'.

> The more I think about it the more I lean toward treating both 
> scenarios equally, i.e. create a new UI in both scenarios, in other 
> words create a new UI for every debug request.
>

Ok. Yes, this was enough to convince me. The debugger is a special tool. 
It is reasonable to always start a fresh UI process for it. In OS level 
debuggers, common practice is to start a debugger (in its own OS 
process) and then 'attach' it to the process being debugged. Makes sense.

> The main difference between the two scenarios is *where* - at which 
> queue the UI process is waiting when the debug request occurs: whether 
> on a Semaphore or on a Processor's ready list (apologies for stating 
> the obvious: the UI process is waiting somewhere by definition when a 
> debug request from another process occurs). I'm aware my experience is 
> very limited but I can't come up with any argument why *not* treat 
> them equally :) Treating them equally looks to me cleaner, simpler and 
> may even allow some more simplifications.
>
> Here's my suggestion (as usual I'm not sure I'm placing my 
> modification at the most appropriate location but you get the idea):
>
> newUIProcessIfNeeded
>
>                 "If the system needs a UIProcess (we know because 
> UIProcess is not nil),
>
>                 then ensure that the UIProcess is ready to run, in 
> order to have a responsive UI.
>
>                 If we needed to create a new UI process, answer the 
> old one, as it is most likely the
>
>                 process the user is interested in debugging. See senders."
>
>                 UIProcess ifNotNil: [ :oldUIProcess |
>
>                                 self spawnNewMorphicProcessFor: UI.
>
>                                 ^oldUIProcess ].
>
>                 ^nil
>

It is reasonable to try that as an experiment, but if you follow the 
several chains of senders to #spawnNewMorphicProcessFor: , you'll see 
this got to dirty, because of making many small, unrelated changes over 
the years. In the current shape of the code it is hard to guarantee that 
all requests to open a debugger behave in a consistent way.

So, I spent a couple of days refactoring and cleaning it. The result is 
18 cleanup & refactor changesets, that shouldn change behavior much, and 
one single change that essentially does what you suggest, but it is now 
much easier to follow. I pushed this to github yesterday. The change 
sets that starts a new process for every debugger (except when the user 
debugs an expression) is in change set #5434.

> With this change the following examples work:
>
> [1/0] fork.
>
> Processor yield.
>
> [ 10000 factorial ] repeat
>
> [1/0] fork.
>
> [ 10000 factorial. Processor yield ] repeat
>
> Surprisingly, even the following example works, i.e. opens a debugger 
> instead of getting stuck, but in this case it is also thanks to some 
> unrelated interrupts at play preempting the old UI and allowing the 
> new UI run..
>
> [1/0] fork.
>
> [ 10 factorial ] repeat
>

Yep. All these work as expected now. It is interesting to open a 
ProcessBrowser, though, and see how the 'former UI process' is still 
busy computing factorials!

> An interesting observation:
>
> The suggested modification works under the assumption that
>
>                 Smalltalk processPreemptionYields
>
> returns true, which is Cuis's default (unlike Squeak's); once you 
> change it to false, i.e. once you change the order ready processes are 
> placed in the Processor's ready queue, it won't work; the preemption 
> mode is critical in this case so I'll have to figure out how to make 
> this work for Squeak :D Or better yet how to make it independent of 
> the processPreemptionYields setting.
>

I think it would be important to understand why would someone want 
#processPreemptionYields = false. Their reasons for requesting a process 
to never yield to others of same priority (even if some higher process 
wakes up in between) may also mean they don't want new UI processes to 
be started so lightly.

> To conclude: if you won't find some fatal flaw with this approach it 
> seems to me it allows to run code fragments in the UI as usual but 
> once a more complex scenario occurs, like a parallel process 
> requesting a debugger, a new UI is created to take over so that the 
> old UI process can continue executing its unfinished task without the 
> need to act as a UI any longer (and will automatically terminate once 
> it finishes its current cycle).
>
> Again, I'll very much appreciate any comments or suggestions you might 
> have; thanks for your time and patience reading such long message :)
>
> Best,
>
> Jaromir
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>

Thanks a lot for trying all these things, suggesting course of action, 
and especially thank you for the great discussion. It is always great to 
be able to talk about these issues. And Cuis is always improving this way!

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220804/fede29c7/attachment.htm>