tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Advice requested regarding [send] on macOS

[Marc C. <cul...@gm...>]

Hi Erik,

Yes, I think it is correct that macOS does not support sending to a
different process.  It supports sending to a different interpreter running
in the same process.  On macOS a Tk "application" is an interpreter, not a
process.

When Tk starts it must create an NSApplication object in order to be able
to process events and draw on the screen.  There is only one instance of
the NSApplication class allowed per process.  Its address is stored in a
global variable NSApp.  There are also restrictions requiring some methods
of Cocoa objects to be called only from the main thread.  I believe that
only the main thread has access to Apple's NSEvent queue.

Apple says "The main thread of the application is responsible for handling
events. Although the Application Kit continues to work if other threads are
involved in the event path, operations can occur out of sequence."

- Marc

On Fri, Aug 15, 2025 at 5:19 AM Erik Leunissen via Tcl-Core <
tcl...@li...> wrote:

> L.S.
>
> My direct question is:
>
> Does macOS support communicating between two interpreters that exist in
> different
> processes, using the Tk command [send] ?
> a. under aqua
> b. under XQuartz
>
>
> Here is the background:
>
> While working on the Tk test suite in project
> simplify_test_utils_for_singleproc_1,
> I made a change that involves the creation of child interpreters in a new
> process.
> That change works fine on all platforms, and doesn't affect the many tests
> that
> use this code.
>
> However, after this change the tests send-8.18 and send-8.19 suddenly fail,
> on macOS only. See at Github [*]:
>
>      https://github.com/tcltk/tk/actions/runs/16958125071/job/48064317915
>
> Please note that the change that I made does not affect [send] or the
> ability
> to use [send] in general [**]. It's just these two extra failing tests on
> macOS.
>
> While searching for the cause of the issue (and already having started a
> first
> debug session), I stumbled over this comment in the test file send.test:
>
>       "#macOS does not send to other processes"
>
> See:
>
> https://core.tcl-lang.org/tk/file?ci=24113d640afeebe2&name=tests%2Fsend.test&ln=185
>
> If that statement is true, than that explains the test failures [***],
> because
> indeed, the two problematic tests do attempt to send to an interpreter in
> another
> process.
>
> However, being unfamiliar with macOS, I'm unsure, especially about the
> difference
> between aqua and XQuartz in this respect. Regarding the latter, the Tcl
> Wiki [****]
> says:
>
>      "The Tk send command depends on working with an X server and thus
> does not
>       work normally on Windows or MacOS."
>
> But this statement doesn't address the case of interpreters in different
> processes.
>
> The answer to my question would be most important to me because I have no
> macOS
> machine available at home to exercise or run tests on. So I'm not in a
> position
> to find such things out for myself.
>
> I'd appreciate very much the your insight,
> Erik Leunissen
>
> --
> [*]    You need to be logged in there.
> [**]   As witnessed by the flawless passing of the many relevant tests
> under
>         Linux, Windows (and macOS at Github).
> [***]  What I don't understand in that case, is that these tests have
> always passed
>         before I changed the code. But I'll gladly forget about that.
> [****] https://wiki.tcl-lang.org/page/send
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] Advice requested regarding [send] on macOS

[Erik L. <el...@xs...>]

L.S.

My direct question is:

Does macOS support communicating between two interpreters that exist in different
processes, using the Tk command [send] ?
a. under aqua
b. under XQuartz


Here is the background:

While working on the Tk test suite in project simplify_test_utils_for_singleproc_1,
I made a change that involves the creation of child interpreters in a new process.
That change works fine on all platforms, and doesn't affect the many tests that
use this code.

However, after this change the tests send-8.18 and send-8.19 suddenly fail,
on macOS only. See at Github [*]:

     https://github.com/tcltk/tk/actions/runs/16958125071/job/48064317915

Please note that the change that I made does not affect [send] or the ability
to use [send] in general [**]. It's just these two extra failing tests on macOS.

While searching for the cause of the issue (and already having started a first
debug session), I stumbled over this comment in the test file send.test:

      "#macOS does not send to other processes"

See:
         https://core.tcl-lang.org/tk/file?ci=24113d640afeebe2&name=tests%2Fsend.test&ln=185

If that statement is true, than that explains the test failures [***], because
indeed, the two problematic tests do attempt to send to an interpreter in another
process.

However, being unfamiliar with macOS, I'm unsure, especially about the difference
between aqua and XQuartz in this respect. Regarding the latter, the Tcl Wiki [****]
says:

     "The Tk send command depends on working with an X server and thus does not
      work normally on Windows or MacOS."

But this statement doesn't address the case of interpreters in different processes.

The answer to my question would be most important to me because I have no macOS
machine available at home to exercise or run tests on. So I'm not in a position
to find such things out for myself.

I'd appreciate very much the your insight,
Erik Leunissen

--
[*]    You need to be logged in there.
[**]   As witnessed by the flawless passing of the many relevant tests under
        Linux, Windows (and macOS at Github).
[***]  What I don't understand in that case, is that these tests have always passed
        before I changed the code. But I'll gladly forget about that.
[****] https://wiki.tcl-lang.org/page/send

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

[Paul O. <pa...@po...>]

Everything fine using macOS and Linux (Suse 15.5, Debian 12.0).
Sorry, no Windows results this time. My Windows machine is dead .-(

Paul

Am 13.08.2025 um 22:02 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.17/
>
> are RC1 candidate source code distribution pre-releases of Tcl and Tk 8.6.17.
>
> These are the second candidate releases leading to the release of Tcl/Tk 8.6.17.
> The target date for release is August 15, 2025.
>
> The Tcl pre-release includes a pre-release of the package Thread 2.8.12,
> The released packages Itcl 4.3.4, TDBC* 1.1.12, and sqlite3 3.50.4 are also included.
>
> Compared to the previous release candidates, both Tcl and Tk include a handful of
> new bug and build fixes.
>
> Please test these candidates on your platforms and report any blocking issues
> you discover.
>
> Thank you for your contributions and assistance.
>

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

[Erik L. <el...@xs...>]

Summary
=======
No blocking issues, just some compile-stage warnings:

- regular build for x86_64-linux on x86_64-linux: 2 compile warnings for Tk (when using optimization 
-O3). Build completed.
- cross-build for x86_64-mingw32 on x86_64-linux: 2 compile warnings for Tk (when using optimization 
-O3). Build completed.

Compile warnings appended.

Regards,
Erik.
--
Compile warnings

For Tk 2 compiler warnings, x86_64-linux:

/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c: In function ‘TkPostscriptImage’:
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1197:37: warning: ‘cdata.blue_mask’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                      ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.blue_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1196:37: warning: ‘cdata.green_mask’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                      ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.green_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1195:37: warning: ‘cdata.red_mask’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                      ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.red_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1197:50: warning: ‘cdata.blue_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                                   ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.blue_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1195:49: warning: ‘cdata.red_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                                  ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.red_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1196:51: warning: ‘cdata.green_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                                    ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.green_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~

-- AND --

/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkTextImage.c: In function ‘EmbImageDisplayProc’:
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkTextImage.c:669:5: warning: ‘imageY’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
      Tk_RedrawImage(image, 0, 0, width, height, dst, imageX, imageY);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- end compiler warnings, Tk, for x86_64-linux on x86_64-linux --

/usr/local/src/SOURCES/tk8.6.17/generic/tkImgGIF.c: In function 'Compress.constprop':
cc1: warning: '__builtin_memset' offset [-25769803700, -64] is out of the bounds [0, 40360] of 
object 'state' with type 'GIFState_t' {aka 'struct <anonymous>'} [-Warray-bounds]
/usr/local/src/SOURCES/tk8.6.17/generic/tkImgGIF.c:1999:16: note: 'state' declared here
  1999 |     GIFState_t state;
       |                ^~~~~
cc1: warning: '__builtin_memset' offset [-25769803700, -64] is out of the bounds [0, 40360] of 
object 'state' with type 'GIFState_t' {aka 'struct <anonymous>'} [-Warray-bounds]

-- AND --

/usr/local/src/SOURCES/tk8.6.17/generic/tkTextImage.c: In function 'EmbImageDisplayProc':
/usr/local/src/SOURCES/tk8.6.17/generic/tkTextImage.c:669:5: warning: 'imageY' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   669 |     Tk_RedrawImage(image, 0, 0, width, height, dst, imageX, imageY);
       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- end compiler warnings, Tk, for x86_64-mingw32 on x86_64-linux --

Re: [TCLCORE] TIP 726 - looking for comments

[<apn...@ya...>]

Heads up: CFV for TIP 726 coming up in a couple of days.

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Sunday, July 27, 2025 11:03 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 726 - looking for comments

 

TIP 726 (https://core.tcl-lang.org/tips/doc/trunk/tip/726.md), implementation, test cases and manpages are ready for review. Will target a CFV in about two weeks.

 

/Ashok

 

From: apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > 
Sent: Tuesday, July 8, 2025 11:26 AM
To: 'Harald Oehlmann' <har...@el... <mailto:har...@el...> >; tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] TIP 726 - looking for comments

 

Harald, Thanks for the comments. Yes, agree the TIP needs to be restructured. Its current form was meant primarily for discussion purposes. I'll rearrange accordingly.

 

All, the utf8proc library is covered under multiple "MIT" licenses. See https://github.com/JuliaStrings/utf8proc/blob/master/LICENSE.md  The Unicode data license is something Tcl is already subject to as the currently used encoding tables are derived from there. So with respect to TIP 705, I presume no separate TIP is needed to permit code licensed under those terms to be added to the repository. If anyone disagrees, please speak up now.

 

/Ashok

 

-----Original Message-----
From: Harald Oehlmann <har...@el... <mailto:har...@el...> > 
Sent: Monday, July 7, 2025 7:25 PM
To: tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] TIP 726 - looking for comments

 

Hi Ashok,

great work. This is long time awaited feature, very helpful.

For me, this all sounds reasonable.

I am ok with the "unicode" ensemble and the mode names.

It may be added, that those names are also used in other programming 

languages.

Also, the reasoning for the library choice looks good.

It is great to ship the source with TCL to be build together.

 

On the TIP organization, I would prefer a clear and short specification 

at the top (e.g. command, c-api, libraqry choice) and to move all 

alternatives in an own section at the bottom.

 

I am also the opinion, that the used library may vary due to its 

availability, even over platforms or use-cases. For me, the command 

syntax is the main point of the TIP.

 

Thanks for all, GREAT !

Harald

 

 

Am 06.07.2025 um 10:09 schrieb apnmbx-public--- via Tcl-Core:

> I am looking for preliminary comments on TIP 726 ( <https://core.tcl-> https://core.tcl- 

> lang.org/tips/doc/trunk/tip/726.md <https://core.tcl-lang.org/tips/doc/ 

> trunk/tip/726.md>) – commands for Unicode normalization.

> 

> In order to avoid wasted effort in re-implementation I’d appreciate 

> early comments on the choice of libraries in particular. For reasons 

> stated in the TIP, the plan is to implement normalization using the 

> utf8proc library from Julia.

> 

> Also, comments on various choices presented for command naming and 

> placement are preferred sooner than later.

> 

> /Ashok

> 

> 

> 

> _______________________________________________

> Tcl-Core mailing list

>  <mailto:Tcl...@li...> Tcl...@li...

>  <https://lists.sourceforge.net/lists/listinfo/tcl-core> https://lists.sourceforge.net/lists/listinfo/tcl-core

 

 

-- 

ELMICRON Dr. Harald Oehlmann GmbH

Koesener Str. 85

06618 NAUMBURG - Germany

Phone: +49 3445 781120

Direct: +49 3445 781127

 <http://www.Elmicron.de> www.Elmicron.de

German legal references:

Geschaeftsfuehrer: Dr. Harald Oehlmann

UST Nr. / VAT ID No.: DE206105272

HRB 212803 Stendal

Re: [TCLCORE] Review of branch bug-87b69745be

[Christian W. <Chr...@t-...>]

On 08/14/2025 08:47 AM, apn...@ya... wrote:

> Not commenting on the pros and cons of 509, but rather that it exchanges
> deadlocks for corruption. Am I incorrect ?

Yes, indeedly. We had to choose between a rock and a hard place.

BR,
Christian

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

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

Am 13.08.2025 um 22:02 schrieb Donald G Porter via Tcl-Core:
> 
> Now available at
> 
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.17/
> 
> are RC1 candidate source code distribution pre-releases of Tcl and Tk 
> 8.6.17.

Thanks Don & Team,here is the report on archaic MS-VC6 32 bit on MS-WS 
11 64 bit.
As in the past, some people cared, here is the report.
It can be ignored as always.
There are compilation warnings and one test failure below

Thanks for all,
Harald

Compilation:

C:\test\tcl8.6.17\tcl8.6.17\win\..\generic\tclProc.c(2275) : warning 
C4550: expression evaluates to a function which is missing an argument list

C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(2720) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4050) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4095) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(1474) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4530) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4550) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4588) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4646) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(5297) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(5489) 
: warning C4761: integral size mismatch in argument; conversion supplied

C:\test\tcl8.6.17\tk8.6.17\win\..\generic\tkCanvas.c(4241) : warning 
C4022: 'memcpy' : pointer mismatch for actual parameter 1

C:\test\tcl8.6.17\tk8.6.17\win\..\win\tkWinFont.c(1499) : warning C4761: 
integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tk8.6.17\win\..\win\tkWinFont.c(1521) : warning C4761: 
integral size mismatch in argument; conversion supplied

C:\test\tcl8.6.17\tk8.6.17\win\..\generic\ttk\ttkFrame.c(175) : warning 
C4005: 'DEFAULT_BORDERWIDTH' : macro redefinition
  
C:\test\tcl8.6.17\tk8.6.17\win\..\generic\ttk\ttkClassicTheme.c(0) : see 
previous definition of 'DEFAULT_BORDERWIDTH'



SQLite does not compile. This is known and ok.

Tests:
Test failures: "exec-bug-4f0b5767ac exec App Execution Alias"

==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
==== Contents of test case:

     exec winget --info

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't execute "winget": no such file or directory
     while executing
"exec winget --info"
     ("uplevel" body line 2)
     invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== exec-bug-4f0b5767ac FAILED

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

[<apn...@ya...>]

Win 10, Visual Studio 2022, x64, x86 Tcl+pkgs, Tk - passed
Ubuntu 20 x64 Tcl+pkgs - passed

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Thursday, August 14, 2025 1:32 AM
To: Tcl List Core <tcl...@li...>
Subject: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates


Now available at

https://sourceforge.net/projects/tcl/files/Tcl/8.6.17/

are RC1 candidate source code distribution pre-releases of Tcl and Tk
8.6.17.

These are the second candidate releases leading to the release of Tcl/Tk
8.6.17.
The target date for release is August 15, 2025.

The Tcl pre-release includes a pre-release of the package Thread 2.8.12,
The released packages Itcl 4.3.4, TDBC* 1.1.12, and sqlite3 3.50.4 are also
included.

Compared to the previous release candidates, both Tcl and Tk include a
handful of
new bug and build fixes.

Please test these candidates on your platforms and report any blocking
issues
you discover.

Thank you for your contributions and assistance.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Review of branch bug-87b69745be

[<apn...@ya...>]

chw wrote:
> Let me politely express my impressions: TIP#509 although positively voted,
was a mistake.

Can't comment on introduction of recursive mutexes as to whether useful or
not, but reading the TIP it seems to me it did not serve the original
purpose of solving deadlocks with respect to signal handlers.

Or to be precise, hasn't the deadlock problem been solved at the expense of
data corruption?

The main thread holds a mutex to ensure exclusive access to the protected
data while it is being manipulated. If the signal handler runs while the
main thread is still in the process of modifying it, and gets the recursive
lock, isn't that presumption of exclusive access broken leading to potential
corruption with the signal handler working with data that may not be in a
consistent state?

Not commenting on the pros and cons of 509, but rather that it exchanges
deadlocks for corruption. Am I incorrect ?

/Ashok

-----Original Message-----
From: Christian Werner <Chr...@t-...> 
Sent: Wednesday, August 13, 2025 11:31 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Review of branch bug-87b69745be

For the record: the Win32 implementation of wait on condition seems
broken, too. Due to Win32 critical sections supporting nesting, the
logical unlock before the wait on condition *must* leave the critical
section as many times as it was entered and restore this afterwards.
Otherwise the mutex is locked during the wait, and that violates the
contract.

Just some thoughts of a Windows noob,
Christian


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Review of branch bug-87b69745be

[<apn...@ya...>]

Indeed true afaics. Condition variables seem broken on all platforms when
locks are recursively held. While your patch would fix Unix, I don't think
the Windows implementation has a wrapper around CriticalSection that
maintains a count. I also don't think the recursion count is available
through a Windows API either so either we have to add a wrapper around the
critical section a la Unix or switch the Windows implementation to use
native condition variables which do handle recursive locks correctly.

This must be fixed before the next 9.x release (since 8.6 does not suffer
from this issue)

/Ashok

-----Original Message-----
From: Christian Werner <Chr...@t-...> 
Sent: Wednesday, August 13, 2025 11:31 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Review of branch bug-87b69745be

For the record: the Win32 implementation of wait on condition seems
broken, too. Due to Win32 critical sections supporting nesting, the
logical unlock before the wait on condition *must* leave the critical
section as many times as it was entered and restore this afterwards.
Otherwise the mutex is locked during the wait, and that violates the
contract.

Just some thoughts of a Windows noob,
Christian


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Review of branch bug-87b69745be

[<apn...@ya...>]

The original thread has gotten sidetracked a bit with locking issues none of
which affect the branch under discussion. Concluding no one has objections,
will merge.

[TCLCORE] Tcl/Tk 8.6.17 Release Candidates

[Donald G P. <don...@ni...>]

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/8.6.17/

are RC1 candidate source code distribution pre-releases of Tcl and Tk 8.6.17.

These are the second candidate releases leading to the release of Tcl/Tk 8.6.17.
The target date for release is August 15, 2025.

The Tcl pre-release includes a pre-release of the package Thread 2.8.12,
The released packages Itcl 4.3.4, TDBC* 1.1.12, and sqlite3 3.50.4 are also included.

Compared to the previous release candidates, both Tcl and Tk include a handful of
new bug and build fixes.

Please test these candidates on your platforms and report any blocking issues
you discover.

Thank you for your contributions and assistance.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Pain points as a distro maintainer

[Pietro C. <ga...@ga...>]

It's fine either way, I can pull Thread 3.0.4 from anywhere, once it's 
released. Thanks all for this!

On Aug 13 2025, 13:26 +0000, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
>I agree with Jan. Presumably, it does not impede Pietro as he can always pull from that branch (or main branch once its merged.)
>
>-----Original Message-----
>From: Jan Nijtmans <jan...@gm...>
>Sent: Wednesday, August 13, 2025 6:06 PM
>To: Donald Porter <d.g...@co...>
>Cc: apn...@ya...; tcl...@li...
>Subject: Re: [TCLCORE] Pain points as a distro maintainer
>
>Op wo 13 aug 2025 om 14:26 schreef Donald Porter:
>> Do you wish to merge this to trunk so that Thread 3.0.4 (or 3.1 ?) supports Tcl 8.6 ?
>>
>> After that I could revise the Tcl 8.6.17 release to bundle both Thread 2,8,12 and Thread 3.0.4
>
>I would prefer to wait. It's so fresh, better let more people test it before
>rushing it in. We can release Thread 3.0.4 with this change later, and
>people who want to use it with Tcl 8.6 can just drop it in there.
>
>I see no reason to delay Tcl 8.6.17 for this.
>
>Regards,
>      Jan Nijtmans
>
>
>
>_______________________________________________
>Tcl-Core mailing list
>Tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] Review of branch bug-87b69745be

[Christian W. <Chr...@t-...>]

For the record: the Win32 implementation of wait on condition seems
broken, too. Due to Win32 critical sections supporting nesting, the
logical unlock before the wait on condition *must* leave the critical
section as many times as it was entered and restore this afterwards.
Otherwise the mutex is locked during the wait, and that violates the
contract.

Just some thoughts of a Windows noob,
Christian

Re: [TCLCORE] Review of branch bug-87b69745be

[Christian W. <Chr...@t-...>]

On 08/13/2025 07:34 PM, Christian Werner wrote:
> On 08/13/2025 07:21 PM, Christian Werner wrote:
>> On 08/13/2025 07:10 PM, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:
>>
>>> Hmm, sorry, my mistake - it seems to be indeed implemented (TIP#509 <https://core.tcl-lang.org/tips/doc/trunk/tip/509.md>, 8.7+).
>>> (I get it from the documentation of 8.6, must hold it now in memory for 8.7+).
>>> …
>>
>> Regarding emulated recursive mutexes on POSIX systems which do not have them natively I have to
>> record, that the wait functions on condition variables seem to be severely broken w.r.t. mutex
>> ownership and lock count: they simply don't honor the fact of a recursively locked mutex so
>> the former owner may get lost and so does its lock count. Bummer!
>
> Here's the fix: …

Oh no, ignore the last diff from my half bakery. This is better:

Index: unix/tclUnixThrd.c
==================================================================
--- unix/tclUnixThrd.c
+++ unix/tclUnixThrd.c
@@ -145,20 +145,32 @@
  static void
  PCondWait(
      pthread_cond_t *pcondPtr,
      PMutex *pmutexPtr)
  {
+    int counter = pmutexPtr->counter;
+
+    pmutexPtr->thread = 0;
+    pmutexPtr->counter = 0;
      pthread_cond_wait(pcondPtr, &pmutexPtr->mutex);
+    pmutexPtr->thread = pthread_self();
+    pmutexPtr->counter = counter;
  }
  
  static void
  PCondTimedWait(
      pthread_cond_t *pcondPtr,
      PMutex *pmutexPtr,
      struct timespec *ptime)
  {
+    int counter = pmutexPtr->counter;
+
+    pmutexPtr->thread = 0;
+    pmutexPtr->counter = 0;
      pthread_cond_timedwait(pcondPtr, &pmutexPtr->mutex, ptime);
+    pmutexPtr->thread = pthread_self();
+    pmutexPtr->counter = counter;
  }
  #endif /* HAVE_PTHREAD_MUTEX_RECURSIVE */
  

  /*
   * globalLock is used to serialize creation of mutexes, condition variables,

>>
>> Regards,
>> Christian
>>
>

Re: [TCLCORE] Review of branch bug-87b69745be

[Christian W. <Chr...@t-...>]

On 08/13/2025 07:21 PM, Christian Werner wrote:
> On 08/13/2025 07:10 PM, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:
>
>> Hmm, sorry, my mistake - it seems to be indeed implemented (TIP#509 <https://core.tcl-lang.org/tips/doc/trunk/tip/509.md>, 8.7+).
>> (I get it from the documentation of 8.6, must hold it now in memory for 8.7+).
>> …
>
> Regarding emulated recursive mutexes on POSIX systems which do not have them natively I have to
> record, that the wait functions on condition variables seem to be severely broken w.r.t. mutex
> ownership and lock count: they simply don't honor the fact of a recursively locked mutex so
> the former owner may get lost and so does its lock count. Bummer!

Here's the fix:

Index: unix/tclUnixThrd.c
==================================================================
--- unix/tclUnixThrd.c
+++ unix/tclUnixThrd.c
@@ -145,20 +145,28 @@
  static void
  PCondWait(
      pthread_cond_t *pcondPtr,
      PMutex *pmutexPtr)
  {
+    int counter = pmutexPtr->counter;
+
      pthread_cond_wait(pcondPtr, &pmutexPtr->mutex);
+    pmutexPtr->thread = pthread_self();
+    pmutexPtr->counter = counter;
  }
  
  static void
  PCondTimedWait(
      pthread_cond_t *pcondPtr,
      PMutex *pmutexPtr,
      struct timespec *ptime)
  {
+    int counter = pmutexPtr->counter;
+
      pthread_cond_timedwait(pcondPtr, &pmutexPtr->mutex, ptime);
+    pmutexPtr->thread = pthread_self();
+    pmutexPtr->counter = counter;
  }
  #endif /* HAVE_PTHREAD_MUTEX_RECURSIVE */
  

  /*
   * globalLock is used to serialize creation of mutexes, condition variables,


>
> Regards,
> Christian
>

Re: [TCLCORE] Review of branch bug-87b69745be

[Christian W. <Chr...@t-...>]

On 08/13/2025 07:10 PM, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:

> Hmm, sorry, my mistake - it seems to be indeed implemented (TIP#509 <https://core.tcl-lang.org/tips/doc/trunk/tip/509.md>, 8.7+).
> (I get it from the documentation of 8.6, must hold it now in memory for 8.7+).
> …

Regarding emulated recursive mutexes on POSIX systems which do not have them natively I have to
record, that the wait functions on condition variables seem to be severely broken w.r.t. mutex
ownership and lock count: they simply don't honor the fact of a recursively locked mutex so
the former owner may get lost and so does its lock count. Bummer!

Regards,
Christian

Re: [TCLCORE] Review of branch bug-87b69745be

[Dipl. I. S. G. B. <se...@us...>]

 

Hmm, sorry, my mistake - it seems to be indeed implemented (TIP#509 [3],
8.7+).
(I get it from the documentation of 8.6, must hold it now in memory for
8.7+). 

Anyway, the "fixed" code is also not worse, even a bit better, because
it saves additional mutex lock if it is unneeded.

Regards,
Serg. 

13.08.2025 18:46, apnmbx-public--- via Tcl-Core wrote: 

> Sergey, 
> 
> I specifically checked the Tcl docs (referencing your update on the ticket) - the Threads manual page - Tcl Library Procedures [2] page says the following: 
> 
> _Tcl_Mutex *mutexPtr (in) A recursive mutex lock._ 
> 
> and later 
> 
> _Mutexes are reentrant: they can be locked several times from the same thread._ 
> 
> Is this not true? My expectation is that Tcl implements recursive mutexes even on system that do not natively have them. I am pretty sure I have noticed other places in the code where a thread takes out recursive locks. 
> 
> If I read the code for Tcl_MutexLock, it maintains a counter and holding thread id while wrapping a native mutex so it seems to be intended to be recursive. 
> 
> Where did you read in Tcls docs that locking a mutex twice from the same thread is undefined? If that is indeed the case the manpage needs to be fixed and quite possibly some code paths as well. 
> 
> I have not reviewed your other mods as resolving the above question first is key. 
> 
> /Ashok 
> 
> FROM: Dipl. Ing. Sergey G. Brester <se...@us...> 
> SENT: Wednesday, August 13, 2025 9:51 PM
> TO: Jan Nijtmans <jan...@gm...>
> CC: apn...@ya...; tcl...@li...
> SUBJECT: Re: [TCLCORE] Review of branch bug-87b69745be 
> 
> But I saw something strange (possible UB on recursive lock).
> I provided a fix and its description in the ticket.
> 
> Regards,
> Sergey. 
> 
> 13.08.2025 14:30, Jan Nijtmans wrote: 
> 
> I looked it over, and don't see anything strange. I welcome the simplification.
> 
> Hope this helps,
> 
> Jan Nijtmans
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://www.tcl-lang.org/man/tcl9.0/TclLib/Thread.html
[3] https://core.tcl-lang.org/tips/doc/trunk/tip/509.md

Re: [TCLCORE] Review of branch bug-87b69745be

[<apn...@ya...>]

Sergey,

 

I specifically checked the Tcl docs (referencing your update on the ticket) – the  <https://www.tcl-lang.org/man/tcl9.0/TclLib/Thread.html> Threads manual page - Tcl Library Procedures page says the following:

 

Tcl_Mutex *mutexPtr (in)  A recursive mutex lock.

 

and later

 

Mutexes are reentrant: they can be locked several times from the same thread.

 

Is this not true? My expectation is that Tcl implements recursive mutexes even on system that do not natively have them. I am pretty sure I have noticed other places in the code where a thread takes out recursive locks.

 

If I read the code for Tcl_MutexLock, it maintains a counter and holding thread id while wrapping a native mutex so it seems to be intended to be recursive.

 

Where did you read in Tcls docs that locking a mutex twice from the same thread is undefined? If that is indeed the case the manpage needs to be fixed and quite possibly some code paths as well.

 

I have not reviewed your other mods as resolving the above question first is key.

 

/Ashok

 

 

 

 

From: Dipl. Ing. Sergey G. Brester <se...@us...> 
Sent: Wednesday, August 13, 2025 9:51 PM
To: Jan Nijtmans <jan...@gm...>
Cc: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] Review of branch bug-87b69745be

 

But I saw something strange (possible UB on recursive lock).
I provided a fix and its description in the ticket.

Regards,
Sergey.

13.08.2025 14:30, Jan Nijtmans wrote:

I looked it over, and don't see anything strange. I welcome the simplification.
 
Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] Review of branch bug-87b69745be

[Dipl. I. S. G. B. <se...@us...>]

 

But I saw something strange (possible UB on recursive lock).
I provided a fix and its description in the ticket.

Regards,
Sergey. 

13.08.2025 14:30, Jan Nijtmans wrote: 

> I looked it over, and don't see anything strange. I welcome the simplification.
> 
> Hope this helps,
> Jan Nijtmans
 

Re: [TCLCORE] Review of branch bug-87b69745be

[<apn...@ya...>]

Thanks for taking a look, a second pair of eyes always appreciated. Will merge post a CI run.

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Wednesday, August 13, 2025 6:01 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] Review of branch bug-87b69745be

Op ma 11 aug 2025 om 19:24 schreef Ashok:
>
> I plan to merge branch bug-87b69745be to the core-9-0-branch and main branches.
>
> Please suggest improvements, objections or other comments by the end of this week.

I looked it over, and don't see anything strange. I welcome the simplification.

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] Pain points as a distro maintainer

[<apn...@ya...>]

I agree with Jan. Presumably, it does not impede Pietro as he can always pull from that branch (or main branch once its merged.)

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Wednesday, August 13, 2025 6:06 PM
To: Donald Porter <d.g...@co...>
Cc: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] Pain points as a distro maintainer

Op wo 13 aug 2025 om 14:26 schreef Donald Porter:
> Do you wish to merge this to trunk so that Thread 3.0.4 (or 3.1 ?) supports Tcl 8.6 ?
>
> After that I could revise the Tcl 8.6.17 release to bundle both Thread 2,8,12 and Thread 3.0.4

I would prefer to wait. It's so fresh, better let more people test it before
rushing it in. We can release Thread 3.0.4 with this change later, and
people who want to use it with Tcl 8.6 can just drop it in there.

I see no reason to delay Tcl 8.6.17 for this.

Regards,
      Jan Nijtmans

Re: [TCLCORE] Pain points as a distro maintainer

[Jan N. <jan...@gm...>]

Op wo 13 aug 2025 om 14:26 schreef Donald Porter:
> Do you wish to merge this to trunk so that Thread 3.0.4 (or 3.1 ?) supports Tcl 8.6 ?
>
> After that I could revise the Tcl 8.6.17 release to bundle both Thread 2,8,12 and Thread 3.0.4

I would prefer to wait. It's so fresh, better let more people test it before
rushing it in. We can release Thread 3.0.4 with this change later, and
people who want to use it with Tcl 8.6 can just drop it in there.

I see no reason to delay Tcl 8.6.17 for this.

Regards,
      Jan Nijtmans

Re: [TCLCORE] Review of branch bug-87b69745be

[Jan N. <jan...@gm...>]

Op ma 11 aug 2025 om 19:24 schreef Ashok:
>
> I plan to merge branch bug-87b69745be to the core-9-0-branch and main branches.
>
> Please suggest improvements, objections or other comments by the end of this week.

I looked it over, and don't see anything strange. I welcome the simplification.

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] Pain points as a distro maintainer

[Donald P. <d.g...@co...>]

> On Aug 13, 2025, at 8:17 AM, Jan Nijtmans <jan...@gm...> wrote:
> 
> Op di 12 aug 2025 om 19:01 schreef Ashok:
>> As for thread, I committed a
>> branch thread9-for-tcl8 in the thread repository that builds (and passes the
>> test suite for whatever that's worth) with both Tcl 8 and Tcl 9. I am not
>> entirely sure why that was not done to begin with but I believe based on the
>> discussion at the last meet, the issue was not so much with 8.6
>> compatibility but with earlier versions. If there are no objections from
>> anyone, it can be merged into the main branch of thread. I'm not sure if
>> that is too late to help you but in any case, I don't think you need to
>> worry about needing a separate 8/9 ports for every extension. They may of
>> course have to be installed in separate directories as most pkgIndex files
>> are not written to choose the appropriate shared library to load.
> Indeed, that was the work still missing. Completed now:
>     <https://core.tcl-lang.org/thread/info/c339140d1c367beb>
> With this, "make dist", and unpacking the archive in a 8.6,
> 9.0 or 9.1 environment all work ;-)
> 
> Limiting thread 3 to Tcl 9.x made some code cleanups
> possible that wouldn't be possible otherwise. You simply
> put back the compatibility stuff for Tcl 8.6, which is fine.
> 
> Since the work is done, we might as well provide it
> to people who want it. Why not?

Do you wish to merge this to trunk so that Thread 3.0.4 (or 3.1 ?) supports Tcl 8.6 ?

After that I could revise the Tcl 8.6.17 release to bundle both Thread 2,8,12 and Thread 3.0.4

DGP