tcl 8.6.13, Linux and Windows.

I have an application which currently uses c++ std::thread() to create
new threads¹ , and then uses some TCL C API which does not require an
interp.

I wonder whether that is safe to do, or whether it is *required* to use
Tcl_CreateThread() instead to create the new threads.

My main concern is the thread specific data which might get accessed by
TCL under the hood in the C API. Looking at the relevant code it seems
that the TSD is initialized in a 'safe' way every time the functions
need to access it (
ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
...
)
R'
---
¹ using c++ std::thread is more convenient when it comes to
specifying the startup-c++ object member function

On 6/21/2023 12:58 PM, Ralf Fassel wrote:
> tcl 8.6.13, Linux and Windows.
>
> I have an application which currently uses c++ std::thread() to create
> new threads¹ , and then uses some TCL C API which does not require an
> interp.
>
> I wonder whether that is safe to do, or whether it is *required* to use
> Tcl_CreateThread() instead to create the new threads.
>

If you are not using or activating Tcl's thread mechanism in some way,
it should play with C++'s threads just fine. This is what Tcl was first
designed to do: be a tool command language for your C++ application :-)

The main thing you have to be sure of is that if you do create an interpreter, it must run in the same thread that created it and it must be destroyed in the same thread that created it. Since you say you are using interfaces that don't require an interpreter, I think you are safe. If you want to use an interpreter, you can do that, but you just have to keep track of the thread to interpreter relationship.

* Phillip Brooks <philbrks@gmail.com>
| The main thing you have to be sure of is that if you do create an
| interpreter, it must run in the same thread that created it and it
| must be destroyed in the same thread that created it. Since you say
| you are using interfaces that don't require an interpreter, I think
| you are safe. If you want to use an interpreter, you can do that, but
| you just have to keep track of the thread to interpreter relationship.

I think in that case (using an interp in a second thread) I would go the
script level thread creation anyway, where you get it all "for free".

My use case is asynchronous reading data from Tcl_Channels (sockets)
which are created in main thread and transferred to the new thread via
Tcl_CutChannel/Tcl_SpliceChannel (the reading must take place regardless
of whether the main thread is blocked somehow, so fileevents are not an
option). The thread-specific data structs which are used to manage the
Tcl_Channels behind the scenes are initialized as required by TCL - a
really Good Thing¹.

TNX
R'
---
¹ http://www.catb.org/jargon/html/G/Good-Thing.html