Tcl package Thread source code

There's a problem with TIP#609 and nesting event handling
through Tcl_ServiceEvent(). If another level of event loop
is started, the thread's event queue remains non-empty, i.e.
the potentially required Tcl_ThreadAlert() to kick the event
loop is not carried out for the TCL_QUEUE_ALERT_IF_EMPTY flag.

While the TIP#609 text correctly describes what that flag is
doing, the notifier in tclNotify.c should possibly be enhanced
to account for the nesting problem, see this check in on
www.androwish.org:

  https://www.androwish.org/home/info/1c860fd4ba26c14f

How did I observe this problem?

My little barcode reader dialog zbartool
(see https://www.androwish.org/home/file?name=assets/zbartool0/zbartool.tcl&ci=tip)
uses the packages tcluvc (POSIX) or tclwmf (Win32) for acquiring
camera pictures and the zbar package in asynchronous mode for barcode
detection. This involves a private worker thread per package which
uses Tcl_Events and TCL_QUEUE_ALERT_IF_EMPTY to communicate with the
foreground Tcl thread. The dialog itself is modal, i.e. it makes its
own event loop using vwait. If I invoke the dialog manually from the
wish command line, the camera seems to freeze, since the dialog had
opened it's (nested) event loop from the Tcl_Eval() of the asynchronous
file handler reading the console. Each event (e.g. mouse motion)
shortly unfreezes. Using the same sequence of commands from a script
does not show this effect, since the first level event loop from the
interactive command line does not exist.

And accordingly logged a reference to this from https://core.tcl-lang.org/tcl/tktview/c7e4c4586d917b42dccb9bc0edc5bac06ec5f39e

Sorry to be so pedantic but important to be able to track Tcl patch level changes from the bug data base. IMO.

FWIW, I agree with @chw regarding a ticket in Tcl regarding this issue or at least a reference for tracking purposes. The purpose of the Thread extension is to make Tcl's threading visible at script level. Tcl itself has threads regardless.
The problem can manifest itself without the thread extension and in fact has nothing to do with the extension implementation so I'm not sure why the ticket is here in the first place.

The CI run was successful as far as I can see. And meanwhile
I've managed to setup my above described test scenario with
both current trunk and trunk with the fix. Indeed does it fix
the problem, thus I strongly prefer that this gets committed
in the 9.0.1 release.

I'm not so worried about regressions in this patch. But I don't know if it helps in your test scenario. If it turns out not to be helpful after all, it's not worth to take the risk of any regression (however small that risk is)

A full regression-test run for this branch will be done tonight in GITHUB

Jan,

should I have messed things up with this patch, I would expect
that the normal Tcl test suite should indicate errors, since the
tclIORChan.c and tclIORTrans.c modules are using the flag, too.
Let's be optimists. In order to setup the described test scenario,
I'll have to prepare many things first, but I'm afraid I'm too
short of time for it due 9.0.1 soon to arrive.

branch created.

Looks good to me, and there is no possibility for regression: as long as the TCL_QUEUE_ALERT_IF_EMPTY flag is not set, everything behaves as in Tcl 8.6. So, it's quite harmless to put this in Tcl 9.0.1.

Let me know your test results. If it works as you expect, I'll happily merge it (or you can do it: You have developer rights now)

I don't think it's worth to move this ticket to the Tcl tracker. The problem only happens with threads enabled, so the relation with "Thread" is clear.

See attachment against current trunk. But I didn't test it.

> A better (later) version is in ...

Are you sure this is the final version of the fix? If so, can you create a patch for Tcl 9.0, with all changes combined?

Thanks!

The above mentioned check-in was my first attempt to fix it.
A better (later) version is in

  https://www.androwish.org/home/info/c9c9c6a82df9e545

And please would some expert please cross link this
ticket to the Tcl repo, too? Thank you.