Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Rich <rich@example.invalid>
Newsgroups: comp.lang.tcl
Subject: Re: Thread with -async exits prematurely
Date: Fri, 28 Jun 2024 16:14:07 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <v5mngf$3dht6$1@dont-email.me>
References: <6672b7d6$0$705$14726298@news.sunsite.dk> <v4uru4$21ajj$1@dont-email.me> <667c6991$0$706$14726298@news.sunsite.dk> <v5i3p0$2bch1$1@dont-email.me> <v5i9qr$2co9k$1@dont-email.me> <667ec02b$0$705$14726298@news.sunsite.dk>
Injection-Date: Fri, 28 Jun 2024 18:14:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="100d8aac9b0387cc56bdc40c71667406";
	logging-data="3590054"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/l6PE9RcTGqi6BTgYWoFdx"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Cancel-Lock: sha1:uTJkvSa+rju7Pknpfcyshqu2HYg=
Bytes: 3909

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.