On Sun, Nov 3, 2019 at 1:48 AM Pratyush Yadav me-at-yadavpratyush.com
|GitHub Public/Example Allow| [off-list ref] wrote:

quoted

+             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