Re: [TCLCORE] Atomicity in Tcl and Tk

[Harald O. <har...@el...>]

Am 14.10.2024 um 16:55 schrieb Marc Culler:
> I have a question for the experts.  It has to do with when the 
> interpreter, during execution of a script, allows idle tasks and timer 
> tasks to be run.
> 
> There is an expectation in may situations that idle tasks will not be 
> run between two consecutive commands in the script.  For example, in 
> macosx/README it says:
> 
> The TkAqua-specific command [tk::unsupported::MacWindowStyle style] is 
> used to
> get and set macOS-specific toplevel window class and attributes. Note that
> the window class and many attributes have to be set before the window is 
> first
> mapped for the change to have any effect.
> 
> That means that the following code is expected to work:
>    toplevel .t
>    tk::unsupported::MacWindowStyle style .t modal
> 
> but something like this:
> 
>    toplevel .t
>    < lots of code here>
>    tk::unsupported::MacWindowStyle modal
> 
> will probably not work because the window will get mapped during the 
> <lots of code>.  The window actually gets mapped in an idle task that is 
> created by the toplevel command.  The first code block works because 
> that idle task gets run after the MacWindowStyle command has run.
> 
> My question is essentially "How large can the <lots of code> be and have 
> this still work?"  What are the rules?  When running a script, when does 
> the interpreter pause and "return to the event loop"?  Is there some way 
> to ensure that a given block of code will run completely before any 
> additional idle tasks get run?

The code should not contain any invocations of the event loop.
Normal commands doing this are:
- update
- vwait
- tkwait
Extensions may define commands which also invoke the event loop.
And any library code may do so.

IMHO code invoking the event queue should be flagged as such.

A good design of event loop awareness is the http package.
You have two operation modes:
- with command option -> call does not invoke event loop
- without command option -> call invokes the event loop
I always prefer the first solution. Invoking the event loop within a 
command is problematic, as the execution time may not be predicted. 
vwait are nesting. And if within a vwait happens another vwait, the 
outer have to wait for the end of all.

Take care,
Harald