• tcl threads benefits

    From Oleg Nemanov@21:1/5 to All on Thu Aug 26 03:47:32 2021
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and data(actually it can with tsv package, but this is discouraged, if I'm not mistaken). Each thread
    contain a separate interpreter with needed libs(included by source command). So, what benefits of tcl threads vs separate processes?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From EL@21:1/5 to Oleg Nemanov on Thu Aug 26 11:07:12 2021
    Oleg Nemanov <oleg.o.nemanov@gmail.com> wrote:

    If i understand correctly, tcl threads doesn't share a code and
    data(actually it can with tsv package, but this is discouraged, if I'm
    not mistaken). Each thread
    contain a separate interpreter with needed libs(included by source command). So, what benefits of tcl threads vs separate processes?


    The „interprocess communication“ is easier, done with thread::send & co. The synchronization of parallel code is easier, you have mutexes and
    condition variables, and unwinding on error. And you can easily transfer channels between threads, which is not possible with separate processes.

    Different interpreters are not a big problem, as long as you don’t have complex data to share. Then in turn , the less data you share, the less
    data needs to be synchronized for concurrent access, so it might even be
    good to have separate interpreters.


    --
    EL

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Oleg Nemanov on Thu Aug 26 12:00:27 2021
    Oleg Nemanov <oleg.o.nemanov@gmail.com> wrote:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and
    data(actually it can with tsv package, but this is discouraged, if
    I'm not mistaken).

    You are mistaken. The tsv package is the proper way to "share" data
    between threads. With that said, there can be a performance reduction
    with the thread synchronization required for proper sharing. But this
    issue occurs with *all* threads systems, it is not unique to Tcl's
    variant.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From oleg.o.nemanov@gmail.com@21:1/5 to All on Thu Aug 26 05:22:11 2021
    четверг, 26 августа 2021 г. в 15:00:32 UTC+3, Rich:
    Oleg Nemanov <oleg.o....@gmail.com> wrote:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and data(actually it can with tsv package, but this is discouraged, if
    I'm not mistaken).
    You are mistaken. The tsv package is the proper way to "share" data
    between threads.

    I meant that data sharing is discouraged, not tsv :-).
    My question was, if we don't use tsv and due to tcl do not share code and data between threads, then the only benefit of tcl threads vs processes may be a little
    more fast message passing betwen threads(vs between processes), isn't it? Or i miss something?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerald Lester@21:1/5 to oleg.o....@gmail.com on Thu Aug 26 07:48:42 2021
    On 8/26/21 7:22 AM, oleg.o....@gmail.com wrote:
    четверг, 26 августа 2021 г. в 15:00:32 UTC+3, Rich:
    Oleg Nemanov <oleg.o....@gmail.com> wrote:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and
    data(actually it can with tsv package, but this is discouraged, if
    I'm not mistaken).
    You are mistaken. The tsv package is the proper way to "share" data
    between threads.

    I meant that data sharing is discouraged, not tsv :-).
    My question was, if we don't use tsv and due to tcl do not share code and data
    between threads, then the only benefit of tcl threads vs processes may be a little
    more fast message passing betwen threads(vs between processes), isn't it? Or i miss something?


    Start up time is way lower.

    Not sharing code and data makes debugging, in other words getting
    correct code, way way way way more easier!

    --
    +----------------------------------------------------------------------+
    | Gerald W. Lester, President, KNG Consulting LLC |
    | Email: Gerald.Lester@kng-consulting.net | +----------------------------------------------------------------------+

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From oleg.o.nemanov@gmail.com@21:1/5 to All on Thu Aug 26 08:03:38 2021
    четверг, 26 августа 2021 г. в 15:48:49 UTC+3, Gerald Lester:
    Start up time is way lower.
    With processes or threads?

    Not sharing code and data makes debugging, in other words getting
    correct code, way way way way more easier!

    Agree. But in this case(not sharing code and data) why simply not use several processes instead of several threads?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From oleg.o.nemanov@gmail.com@21:1/5 to All on Thu Aug 26 08:40:48 2021
    четверг, 26 августа 2021 г. в 18:31:28 UTC+3, Harald Oehlmann:
    Am 26.08.2021 um 12:47 schrieb Oleg Nemanov:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and data(actually it can with tsv package, but this is discouraged, if I'm not mistaken). Each thread
    contain a separate interpreter with needed libs(included by source command).
    So, what benefits of tcl threads vs separate processes?

    Another aspect I like with threads is, that it is quite easy to control
    them from the master thread. All the tread create/destroy stuff is
    inside TCL.

    Ok. +1 to threads advantages over processes :-).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Thu Aug 26 17:31:23 2021
    Am 26.08.2021 um 12:47 schrieb Oleg Nemanov:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and data(actually it can with tsv package, but this is discouraged, if I'm not mistaken). Each thread
    contain a separate interpreter with needed libs(included by source command). So, what benefits of tcl threads vs separate processes?


    Another aspect I like with threads is, that it is quite easy to control
    them from the master thread. All the tread create/destroy stuff is
    inside TCL.

    I personally use Threads only to keep the GUI active.
    If I have a function which blocks to long - take it in a thread and call
    back, if the thread finished work. On the next "update", the answer will
    be there.

    Thanks,
    Harald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Uwe Klein@21:1/5 to All on Thu Aug 26 18:19:00 2021
    Am 26.08.21 um 17:40 schrieb oleg.o....@gmail.com:
    четверг, 26 августа 2021 г. в 18:31:28 UTC+3, Harald Oehlmann:
    Am 26.08.2021 um 12:47 schrieb Oleg Nemanov:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and data(actually it can with tsv package, but this is discouraged, if I'm not mistaken). Each thread
    contain a separate interpreter with needed libs(included by source command).
    So, what benefits of tcl threads vs separate processes?

    Another aspect I like with threads is, that it is quite easy to control
    them from the master thread. All the tread create/destroy stuff is
    inside TCL.

    Ok. +1 to threads advantages over processes :-).

    you can do the same with processes. just use event processing.
    ( I really loved BLT's bgexec )

    cost of another thread versus another process is OS dependent.
    Linux forex used to show no big difference.

    Uwe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christian Gollwitzer@21:1/5 to All on Thu Aug 26 20:03:08 2021
    Am 26.08.21 um 17:03 schrieb oleg.o....@gmail.com:
    четверг, 26 августа 2021 г. в 15:48:49 UTC+3, Gerald Lester:
    Start up time is way lower.
    With processes or threads?


    Threads start faster, of course, then whole processes. Especially on the Windows platform where starting a process is excessively slow.

    Christian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to oleg.o....@gmail.com on Thu Aug 26 17:35:35 2021
    oleg.o....@gmail.com <oleg.o.nemanov@gmail.com> wrote:
    ???????, 26 ??????? 2021 ?. ? 15:00:32 UTC+3, Rich:
    Oleg Nemanov <oleg.o....@gmail.com> wrote:
    Hi, all.

    If i understand correctly, tcl threads doesn't share a code and
    data(actually it can with tsv package, but this is discouraged, if
    I'm not mistaken).

    You are mistaken. The tsv package is the proper way to "share" data
    between threads.

    I meant that data sharing is discouraged, not tsv :-).

    Ah, yes, and that is the case for parallelizing any algorithm.

    My question was, if we don't use tsv and due to tcl do not share code
    and data between threads, then the only benefit of tcl threads vs
    processes may be a little more fast message passing betwen threads(vs
    between processes), isn't it? Or i miss something?

    If you do as you say, then yes, you should have both faster, and
    easier, message passing using the thread::send interfaces vs. having to
    create an IPC system (or use Tcllib's comm).

    And yes, thread::send should in all cases be faster than any
    interprocess communications method.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to oleg.o....@gmail.com on Thu Aug 26 18:22:20 2021
    oleg.o....@gmail.com <oleg.o.nemanov@gmail.com> wrote:
    ???????, 26 ??????? 2021 ?. ? 15:48:49 UTC+3, Gerald Lester:
    Start up time is way lower.
    With processes or threads?

    Not sharing code and data makes debugging, in other words getting
    correct code, way way way way more easier!

    Agree. But in this case(not sharing code and data) why simply not
    use several processes instead of several threads?

    In the case of not sharing any code and any data, and presuming little
    to no "message passing", there is little overall difference.

    With that said, for multiple processes, you have to start the plural
    processes somehow, which either means a higher level "control" (i.e.,
    bash script, dos bat file) which differs between platforms, or setting
    things up properly to be able to launch the multiple Tcl scripts from
    Tcl using 'exec' (here I'm thinking specifically for windows where Tcl
    is, more often than not, a second or third class citizen).

    With Tcl threads, you gain the abililty to launch "plural processes" -
    but by using Tcl commands that work identically across platforms.

    If you do need to do some 'message passing' -- well then the benefit
    there goes to threads, as the 'message passing' is built in to
    thread::send. If you use plural processes, then you have to "add on" a
    message passing framework (or write one yourself).

    One other advantage of Tcl threads is that "message passing" looks
    almost like a remote procedure call of sorts:

    thread::send $thread_id [list command param1 param2 param3 param4]

    And you get your choice of synchronous RPC, a call and wait for
    response later RPC, and a "fire and forget" fully asynchronous RPC.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christian Werner@21:1/5 to All on Thu Aug 26 15:06:35 2021
    There are at least two other not obvious benefits of Tcl threading:

    1. From an extension perspective the Tcl core provides a portability layer of thread support, i.e. a third party library can be interfaced "threaded under the hood" using worker threads without much platform hassle, see my topcua extension in https://
    wiki.tcl-lang.org/page/topcua

    2. Tcl threading extends to Tk, i.e. even stuff requiring a windowing system can be modeled with multiple threads (at least on Windows and X11), IMO almost a unique selling point of the Tcl/Tk combo. Moreover, when using the container/embedding technique
    of Tk toplevels.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rolf Ade@21:1/5 to Oleg Nemanov on Fri Aug 27 01:26:22 2021
    Oleg Nemanov <oleg.o.nemanov@gmail.com> writes:
    If i understand correctly, tcl threads doesn't share a code and data
    [...]
    So, what benefits of tcl threads vs separate processes?

    Your claim is mostly true for the core (the threads share the pwd, and
    channels could be transfert). To conclude that Tcl threads doesn't offer
    much over separate processes miss (beside other things said by others)
    the extendability of Tcl. A binary extension surely is free, to share
    data between Tcl threads.

    As an example tDOM is able to share DOM trees between Tcl threads. The
    Tcl appartment model of threads for the core gives me a language which
    is immune against typical thread problem while working on my shared data
    in parallel in different threads.

    Which reduces the problem of shared data between threads to managing
    read or write locks to my own shared data.

    In other words: What you describe is the solid base to share data
    structures between threads. In your extension. Just get it right.

    Good luck!

    rolf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From EL@21:1/5 to Rolf Ade on Fri Aug 27 04:53:15 2021
    Rolf Ade <rolf@pointsman.de> wrote:

    Which reduces the problem of shared data between threads to managing
    read or write locks to my own shared data.

    In other words: What you describe is the solid base to share data
    structures between threads. In your extension. Just get it right.

    But you must make sure that Tcl_Interp*‘s are not part of that shared data, since they are not (entirely) shared among different threads. It is not possible to call into a Tcl_Interp* from a thread in which it was not initialized.


    --
    EL

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rolf Ade@21:1/5 to elehmann77@gmail.com on Sat Aug 28 00:31:29 2021
    EL <elehmann77@gmail.com> writes:
    Rolf Ade <rolf@pointsman.de> wrote:

    Which reduces the problem of shared data between threads to managing
    read or write locks to my own shared data.

    In other words: What you describe is the solid base to share data
    structures between threads. In your extension. Just get it right.

    But you must make sure that Tcl_Interp*‘s are not part of that shared data, since they are not (entirely) shared among different threads. It is not possible to call into a Tcl_Interp* from a thread in which it was not initialized.

    Thats right. I talked about own data structures. Which should not
    include pointers to Tcl_Interp nor Tcl_Obj.

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