Re: Thread with -async exits prematurely

Luis Mendes <luisXXXlupeXXX@gmail.com> wrote:

Hi et99,
 
Thank you for your help.
 
Please, read below.
 
 
On Wed, 26 Jun 2024 16:56:10 -0700, et99 wrote:

Luis Mendes <luisXXXlupeXXX@gmail.com> wrote:

 

1. Regarding vwait

 
-snip-
 
Care must be taken to -NOT- do any [update] calls or a [vwait] on
another variable any time between the thread::send calls and the vwait
on the variable sync - since all threads are setting the same variable.

Can you please elaborate on this?
any calls?
any update calls?

[update] is the Tk command to explicitly reenter the event loop from
Tcl code.  vwait is an event loop wait command, and 'reentering' the
event loop in the wrong place (per et99's info) may mess up the
handling of the return events from the threads.

the vwait I understand.

vwaits nest, so a second vwait (if called) while an existing vwait is
outstanding must itself first complete before the outer one can
complete.  This too might mess up the handling of the return events
from the threads.

I have a vwait inside the sourced file that is running under some child
thread, it should be fine, right?

If the vwait is in a separate thread, then it has no bearing on a vwait
in "this" thread.  Each thread in Tcl is more similar to a "process" in
Linux/Windows than to a true "thread".  The term used on the wiki is
the "apartment model" of threading.  Each thread is an independent
interpreter that by default shares nothing with other interpreters.

But, I placed some 'after xxxx' commands in between the thread::send and
the vwait sync.
Is it a mistake?

after with just a number does not reenter the event loop, so there
should be no problem there.

The funny thing is that when I first tried this, it worked as you show
above.
But now, everytime I run it, all five threads finish their job.
 
for f in {1..50}; do echo -n "$f -> "; ./et_thread1.tcl | grep 'm=4'; done
 
The last line 'm=4' shows up every time.

Threads (as well as cooperating processes) introduce the aspect of
indeterminism to your code.  Absent explict locking to control
execution order (and if done, esp.  incorrectly, this would often erase
the parallelism available via threads) you have no control over the
order that any thread executes with respect to others.

So some runs, with a given order, finish off properly.

Other runs, with a different ordering of execution, can produce other
results.

Which means that there might need to be some small amount of
"synchronizing" that needs to be done to eliminate the orders that
produce the unwanted results.

Note that et99 and my examples are just that, examples, and don't take
into account all the possibilities nor try to sand off any rough
edges.