Itcl - the [incr Tcl] extension

A pool of list elements is kept in itclUtil.c making use of a few process-global
variables, and no mutex controlled access to them.

This very likely means Itcl's operations are not thread safe.

See a proof-of-concept fix in 

https://www.androwish.org/home/fdiff?v1=299e57d36c78852f&v2=2596d7dc5c2070aa

Well, at the first glance, Itcl doesn't need this listPool of free list elements at all: it simply looks like a kind of additional memory manager (but ckalloc/ckfree is already such, but better if it used threaded), and it is not good approach from point of view of the threads & CPU cache washouts/granularity - change of small memory block by thread A in a larger block of thread B in CPU cache will cause that whole large block will be invalidated in L1/L2 CPU cache and it going to the memory access (what is thousands times slower than L1/L2), especially considering the theoretical fragmentation. The bottom line is that it's a questionable feature, at least in threaded Itcl.

Still worse is that it seems never be designed for threaded usage from scratch, for instance because Itcl_FinishList will be invoked from FreeItclObjectInfo, which is invoked per interpreter and not for the whole library (e. g. get destroyed with every interpreter together with itcl-namespace and not by a callbacks like such of Tcl_CreateExitHandler).

One could rewrite it to use TSD (e. g. a listPool per thread), but then it'd be very similar to threaded-alloc (and marginally faster).

Saying that I tend to remove this "cached" list completely and replace it using internal Tcl's tclobj-cache (per thread), since size of Itcl_ListElem always smaller than Tcl_Obj.

Fixed on my side, but if I try to push it, I get "Error: not authorized to write".
I definitely had write-access previously and still have it on other core.tcl-lang repos... what is wrong here?

Fixed in [9e63c6d8e58ddcad] - it uses threaded-object cache instead of internal pool now.

When I recently faced trouble pushing to core.tcl-lang.org fossil servers,
the trouble was that my fossil sandbox was "logged in" using the domain
name core.tcl.tk and something about the forwarding had apparently
stopped working.

Taking the moment to update my sandboxes to talk to core.tcl-lang.org
directly got me back in business.

Moving the extension Itcl from not-thread-supporting to thread-supporting
strikes me as a big and positive deal.  Well done!

This seems like a good reason to bump to version 4.3.

If someone thinks that's a terrible idea, please say so.

I'm mildly surprised to see this patch applied to the Itcl 3 branch, which
I believed to be long dead.

Does anyone know anyone making use of Itcl 3?

> Taking the moment to update my sandboxes to talk to core.tcl-lang.org directly got me back in business.

Yep, that was also my issue.

> I'm mildly surprised to see this patch applied to the Itcl 3 branch, which I believed to be long dead.

I always try to fix the bug in the branch where it belongs to (or backport the fix hereafter).

> Does anyone know anyone making use of Itcl 3?

But yes, I still do... in some legacy projects of me or in 8.5-based projects (without tclOO), because itcl-4 is tclOO-based thing.