On Sun, Nov 3, 2019 at 1:48 AM Pratyush Yadav me-at-yadavpratyush.com
|GitHub Public/Example Allow| <172q77k4bxwj0zt@xxxxxxxxxxxxxx> wrote:
> > + after idle [list after 0 [list \
> > + delete_helper \
> > $path_list \
> > - [concat $after [list ui_ready]]
> > + $path_index \
> > + $deletion_errors \
> > + $deletion_error_path \
> > + $batch_size \
> > + ]]
>
> Using `after idle` means in theory we put an undefined maximum time
> limit on the deletion process. Though I suspect in real life it would be
> a pretty short time.
>
> Nonetheless, should you instead do this asynchronously, instead of
> waiting for the event loop to enter an idle state? This means using
> `after 0` directly, instead of doing `after idle [list after 0...`. I
> haven't tested it, but AFAIK this should also keep the UI active while
> not depending on the state of the event loop.
>
> What benefits does your way have over just passing the entire list
> (without batching) to an async script to do processing in the
> background?
I forgot to include this in my point-form list at the end of the
preceding e-mail. What should I be looking into to achieve the same
sort of behaviour, where the UI isn't frozen and the user is getting
period updates about the progress of a large deletion, without using
batches on the UI thread? Is that a thing, or am I misunderstanding
you w.r.t. to doing this asynchronously?
For what it's worth, I used `after idle {after 0 ..}` based on the
recommendation of the Tcler's Wiki [0]:
> An after idle that reschedules itself causes trouble, as the manual warns (PYK 2012-09: the docs no-longer contain this warning, but it still applies):
>
> At present it is not safe for an idle callback to reschedule itself
> continuously. This will interact badly with certain features of
> Tk that attempt to wait for all idle callbacks to complete.
> If you would like for an idle callback to reschedule itself
> continuously, it is better to use a timer handler with a zero
> timeout period.
>
> Even this warning is oversimplified. Simply scheduling a timer handler with a zero timeout period can mean that the event loop will never be idle, keeping other idle callbacks from firing. The truly safe approach combines both:
>
> proc doOneStep {} {
> if { [::sim::one_step] } {
> after idle [list after 0 doOneStep]
> #this would work just as well:
> #after 0 [list after idle doOneStep]
> }
> return
> }
> sim::init .c 640 480
> doOneStep
>
> This skeleton should be considered the basic framework for performing long running calculations within a single Tcl interpreter.
Thanks,
Jonathan Gilbert
[0] https://wiki.tcl-lang.org/page/Keep+a+GUI+alive+during+a+long+calculation
