Prev: regsub (and regular expressions in general) trouble.
Next: How to call a tcl script (proc) from a vb.net.
From: Donal K. Fellows on 22 Dec 2009 05:13
On 22 Dec, 03:46, Kevin Kenny <kenn...(a)acm.org> wrote:
> gavino wrote:
> > What will tcl do as more apps run on 16 core box?
> Use thread::create fifteen times?

I'd probably use a thread pool (appropriately scaled) instead.

Donal.
From: pmarin on 22 Dec 2009 07:21
On Dec 22, 2:10 am, gavino <gavcom...(a)gmail.com> wrote:
> erlang and haskell seems to have multicore capability.
>
> What will tcl do as more apps run on 16 core box?

tcl does not use green threads like others ;)
From: tom.rmadilo on 22 Dec 2009 14:50
On Dec 22, 4:21 am, pmarin <pacog...(a)gmail.com> wrote:
> On Dec 22, 2:10 am, gavino <gavcom...(a)gmail.com> wrote:
>
> > erlang and haskell seems to have multicore capability.
>
> > What will tcl do as more apps run on 16 core box?
>
> tcl does not use green threads like others ;)

Thank goodness: No!

Since Tcl has a C API, it is easy to follow the typical pattern for
cross platform multi-threaded application development.

But developers who just use tcl scripting can remain blissfully
unaware of the gory details, just like they can ignore other platform
differences.

There are only a few main reasons to use threads: to allow blocking
channel i/o (usually easier to program), to take advantage of
additional processors, or to conserve/share memory (or other)
resources. In larger applications the advantage is the use of
different pools of specialized threads.

But if you read over the previous paragraph you might notice that the
burden falls on the developer of an application. The programming
language does not "figure out" how to distribute your code across the
available hardware. One of the problems with green threads is the
attempt to make this easy. The result is the need to create serialized
classes or methods which amounts to creating a "critical section" ...
the most expensive form of synchronization. Apparently you can't use
green threads to handle blocking i/o.

Green threads seem to be the product of hostility to an existing
solution and defects in the execution model of the language. Since
each Tcl interp is confined to a single native thread, no work is
expended trying to outsmart the developer. The Tcl execution model is
confined to a single interp, identical to the execution model of
native threads.
From: David Gravereaux on 22 Dec 2009 16:40
Tcl Bliss wrote:
> On Dec 21, 5:10 pm, gavino <gavcom...(a)gmail.com> wrote:
>> erlang and haskell seems to have multicore capability.
>>
>> What will tcl do as more apps run on 16 core box?
>
> Did you miss the train again? ;)

main {} {
rmmadwim
}
main

http://wiki.tcl.tk/11042
--


From: Konstantin Khomoutov on 22 Dec 2009 20:10
On Dec 22, 6:46 am, Kevin Kenny <kenn...(a)acm.org> wrote:

>> erlang and haskell seems to have multicore capability.
>> What will tcl do as more apps run on 16 core box?
> Use thread::create fifteen times?
While the OP is obviously trolling, he does have a point: pure
functional languages allow their runtime to transparently execute
several bits of code in parallel. But as this requires controllable
absence of side effects, it will never be implemented in Tcl.

And Erlang does not do this for sure (at least now)--it only allows
several its lightweight processes to run in parallel (Tcl also doesn't
have anything like this).
As to Haskell, I'm just not familiar with the details.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: regsub (and regular expressions in general) trouble.
Next: How to call a tcl script (proc) from a vb.net.