Although I understand the reason behind the current changes, it would be nice to keep progress bars updating while a new architecture is put in place. Otherwise, this gives the impression that Pharo is frozen during long operations (such as Iceberg cloning/fetching/checking out).
In the case above, the UI thread is blocked in an ffi callout. The callout launches eventually a callback that is executed in a separate process, which in turn triggers an announcement (hoping it updates the UI). Now, since the UI process is blocked in the callout, a UI cycle will never happen.
To see the issue, compare the two following scripts:
total := 200.
job := Job new title: 'x'; min: 0; max: total; yourself.
Job jobAnnouncer announce: (JobStart on: job).
1 to: total do: [ :completed |
[
job current: completed.
Job jobAnnouncer announce: (JobChange on: job).
] forkAt: 61.
10 milliSeconds wait.
].
Job jobAnnouncer announce: (JobEnd on: job).
vs
total := 200.
job := Job new title: 'x'; min: 0; max: total; yourself.
Job jobAnnouncer announce: (JobStart on: job).
1 to: total do: [ :completed |
[
job current: completed.
Job jobAnnouncer announce: (JobChange on: job).
] value.
10 milliSeconds wait.
].
Job jobAnnouncer announce: (JobEnd on: job).
The first one executes the annoucements in a separate thread, but since the UI thread is blocked (executing the script), the progress bar does not refresh.
The second one executes the annoucements in the (current) UI thread and this is refreshed in SpMorphicProgressBarAdapter>>updateState
I propose we change SpMorphicProgressBarAdapter>>updateState as follows, commenting the check for the current UI thread, updating always?
I understand this could bring even more race conditions, but the current situation is not good either.
How can we have a good compromise? Maybe there is another solution in the oven?
Although I understand the reason behind the current changes, it would be nice to keep progress bars updating while a new architecture is put in place. Otherwise, this gives the impression that Pharo is frozen during long operations (such as Iceberg cloning/fetching/checking out).
In the case above, the UI thread is blocked in an ffi callout. The callout launches eventually a callback that is executed in a separate process, which in turn triggers an announcement (hoping it updates the UI). Now, since the UI process is blocked in the callout, a UI cycle will never happen.
To see the issue, compare the two following scripts:
vs
The first one executes the annoucements in a separate thread, but since the UI thread is blocked (executing the script), the progress bar does not refresh. The second one executes the annoucements in the (current) UI thread and this is refreshed in
SpMorphicProgressBarAdapter>>updateState
I propose we change
SpMorphicProgressBarAdapter>>updateState
as follows, commenting the check for the current UI thread, updating always?I understand this could bring even more race conditions, but the current situation is not good either. How can we have a good compromise? Maybe there is another solution in the oven?