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?
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).
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, ifYou are mistaken. The tsv package is the proper way to "share" data
I'm not mistaken).
between threads.
четверг, 26 августа 2021 г. в 15:00:32 UTC+3, Rich:
Oleg Nemanov <oleg.o....@gmail.com> wrote:
Hi, all.You are mistaken. The tsv package is the proper way to "share" data
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).
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.With processes or threads?
Not sharing code and data makes debugging, in other words getting
correct code, way way way way more easier!
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.
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?
четверг, 26 августа 2021 г. в 18:31:28 UTC+3, Harald Oehlmann:
Am 26.08.2021 um 12:47 schrieb Oleg Nemanov:
Hi, all.Another aspect I like with threads is, that it is quite easy to control
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?
them from the master thread. All the tread create/destroy stuff is
inside TCL.
Ok. +1 to threads advantages over processes :-).
четверг, 26 августа 2021 г. в 15:48:49 UTC+3, Gerald Lester:
Start up time is way lower.With processes or threads?
???????, 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?
???????, 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?
If i understand correctly, tcl threads doesn't share a code and data
[...]
So, what benefits of tcl threads vs separate processes?
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 25:35:47 |
Calls: | 6,448 |
Files: | 12,050 |
Messages: | 5,254,341 |