1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • tcl thread creation; c++ std::thread vs Tcl_CreateThread

    From Ralf Fassel@21:1/5 to All on Wed Jun 21 18:58:21 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From saitology9@21:1/5 to Ralf Fassel on Thu Jun 22 11:43:56 2023
    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 :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Brooks@21:1/5 to All on Thu Jul 13 08:50:54 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ralf Fassel@21:1/5 to All on Fri Jul 14 10:54:20 2023
    * Phillip Brooks <[email protected]>
    | 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)