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

[Jaromir Matas]

Hi Juan,

I hate to bring bad news but I’m afraid there’s still one outstanding issue ;)

s := Semaphore new.
[1/0. s signal] fork.
s wait.
Transcript cr; show: 'done'

If you terminate a blocked UI it means it won’t be able to continue when signaled and won’t print ‘done’ in this case.

This feels like a natural requirement for the blocked UI to continue because if it was just a regular non-UI process we would want it continue too, I guess; like this:

[s := Semaphore new.
[1/0. s signal] fork.
s wait.
Transcript cr; show: 'done'] fork

I look forward to hearing from you again, many thanks!

PS: I tried resuming instead of terminating the oldUIProcess but that of course ends up infamously with two UI processes ;)

Best,
Jaromir

--

Jaromír Matas

mail at jaromir.net

From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Saturday, July 2, 2022 21:55
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Freezing UI - can't interrupt via Alt+.

Hi Jaromir,

I think it is fair to say that if the debugger needs to open, there must be a runnable UI process. Just pushed #5347 for that.

I just think that nobody in the Cuis / Squeak community thought about that before.

Thanks!!!

Cheers,

On 7/2/2022 6:03 AM, Jaromir Matas via Cuis-dev wrote:
Hi Juan,

the update indeed works, thanks!
An observation though: if you do:
1) Semaphore new wait
2) Alt+.
3) Proceed
It disrupts the screen and 'restore display' from the World menu is needed; nothing serious, just reporting because I don't know whether this is to be expected or not :)

There's one issue I'd very much like to discuss:

s := Semaphore new.
[1/0. s signal] fork.
s wait

When I first ran this example I kind of hoped the UI would not freeze and would open a debugger on the ZeroDivide. I can't see any reason why not behave like that but both Squeak and Cuis freeze because the UI waits on the semaphore and the forked process requests the UI to open a debugger but the UI is stuck at the semaphore :)

My expectation was the system would spawn a new UI that would open the debugger but I have no experience with UIs and debuggers and can imagine it may be very tricky :)

I'd be very interested in your opinion how the above example could/should be handled by the UI.

Of course if you run the example in a non-UI process it works as expected but it'd be nice I guess if running it in the UI would behave similarly :)

[s := Semaphore new.
[1/0. s signal] fork.
s wait] fork

Many thanks!
Jaromir


--

Jaromír Matas

mail at jaromir.net<mailto:mail at jaromir.net>

From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Saturday, July 2, 2022 1:54
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Freezing UI - can't interrupt via Alt+.

On 7/1/2022 9:45 AM, Juan Vuletich via Cuis-dev wrote:
On 7/1/2022 8:17 AM, Jaromir Matas via Cuis-dev wrote:
Hi Juan, all,

I wonder why this can’t be interrupted by Alt+.

Semaphore new wait

The system returns a message “Can not interrupt background process” and the image has to be closed.

The same happens in this case:

s := Semaphore new.
[1/0. s signal] fork.
s wait

It not only freezes the UI but is not even recoverable…

Thanks,
jaromir


--

Jaromír Matas

mail at jaromir.net<mailto:mail at jaromir.net>


Hi Jaromir,

The problem is in #handleUserInterrupt, in particular in #processTakingMostCPU. #handleUserInterrupt runs on a high priority process, so the first thing it needs to figure out is which process to interrupt. I wrote that code believing that alt+. would need to interrupt busy code, and it works in that case. It doesn't work if the UI process is waiting and never resumed, as it is not "busy".

We need to do better here. I won't be able to work on this for the next few days, but would be very happy if any of you folks suggest / code a solution.

Thanks,


--

Juan Vuletich

www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev

https://github.com/jvuletich

https://www.linkedin.com/in/juan-vuletich-75611b3

https://independent.academia.edu/JuanVuletich

https://www.researchgate.net/profile/Juan-Vuletich

https://patents.justia.com/inventor/juan-manuel-vuletich

https://twitter.com/JuanVuletich

Just pushed a fix. Please review it. It is update #5346.

Thanks!


--

Juan Vuletich

www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev

https://github.com/jvuletich

https://www.linkedin.com/in/juan-vuletich-75611b3

https://independent.academia.edu/JuanVuletich

https://www.researchgate.net/profile/Juan-Vuletich

https://patents.justia.com/inventor/juan-manuel-vuletich

https://twitter.com/JuanVuletich




--

Juan Vuletich

www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev

https://github.com/jvuletich

https://www.linkedin.com/in/juan-vuletich-75611b3

https://independent.academia.edu/JuanVuletich

https://www.researchgate.net/profile/Juan-Vuletich

https://patents.justia.com/inventor/juan-manuel-vuletich

https://twitter.com/JuanVuletich


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