tcl-threads — Discussion of threading in Tcl and the Thread extension.

[Tcl-Threads] maximum number of tcl threads ?

[sanjeevksaxena <san...@in...>]

Hi All,


I am writing a multithreaded test suite using java and TCL. I will have TCL 8.3 with thread extension 2.5 on Solaris 9.0 for development, Can anybody let me know "How many number of threads we can create using thread::create command from a process ?"


Thanks in advance,


Sanjeev Kr Saxena


 


 


 
 Click onthe image to chat with me

[Tcl-Threads] tcl threads and tcl extension dlls

[Huiban Y. <yoa...@si...>]

Hi all,

I'm trying to use tcl udp extension with tcl threads 2.5.
The Tcl udp is a dll which does not seems to be compatible with tcl threads. I will perhaps have to modify it, and I'm looking for sample code.
Where could I find an tcl extension (ie dll or .so) written in C which can run in Threads 2.5 ?

Thanks by advance,
Yoann

Re: [Tcl-Threads] Erlang's mnesia database?

[Andrew P. <at...@pi...>]

On Mon, Oct 06, 2003 at 10:00:41AM -0700, Jeff Hobbs wrote:

> I know nothing about Mnesia, but for in-memory dbs you might want to
> consider sqlite (http://www.sqlite.org/).  It is threadsafe, when

Last I checked, Sqllite does not support concurrency.  (It allows at
best one exclusive writer, multiple readers.  No multiple writers
allowed ever.)

nsv, on the other hand, nicely supports concurrent access from
multiple theads (and the Tcl threads extensions even more so).  I want
something clearly more powerful than nsv, not something which better
in some ways but dramatically worse in at least one major, important
way.

-- 
Andrew Piskorski <at...@pi...>
http://www.piskorski.com

RE: [Tcl-Threads] Erlang's mnesia database?

[Jeff H. <je...@Ac...>]

> AOLserver's nsv API is great, but I've occasionally found the plain
> old key/value pairs of an associative arrays limiting, and really
> wished I had an in-memory relational database available.  So I'm
> wondering if Mnesia would fit that bill..

I know nothing about Mnesia, but for in-memory dbs you might want to
consider sqlite (http://www.sqlite.org/).  It is threadsafe, when
compiled to be so, and has quite the user following.  It has Tcl
bindings (I don't know if it is drop-in-ready for AOLServer).

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
        Tcl Support and Productivity Solutions

[Tcl-Threads] Erlang's mnesia database?

[Andrew P. <at...@pi...>]

Has anyone here learned much about Erlang's "mnesia" database, or
considered whether (and how) it would be feasible to use it from
AOLserver?

  http://www.erlang.org/doc/r9c/lib/mnesia-4.1.4/doc/html/mnesia.html

AOLserver's nsv API is great, but I've occasionally found the plain
old key/value pairs of an associative arrays limiting, and really
wished I had an in-memory relational database available.  So I'm
wondering if Mnesia would fit that bill..

Reportedly, Mnesia's features include: object-relational, in-memory or
on disk, soft real-time, distributed.

It says it supports atomic transactions and concurrency, but I haven't
found any particularly good explanation of how it is similar/different
to other relational databases - what locking model it uses, whether it
supports referential integrity, etc.

Comments?

-- 
Andrew Piskorski <at...@pi...>
http://www.piskorski.com

[Tcl-Threads] Re: [AOLSERVER] Tcl Threads shared memory support?

[Zoran V. <zo...@ar...>]

On Monday 15 September 2003 03:46, you wrote:

> via forked processes and shared memory.  (How true is this really?)

Very true.

>
> So, I'm wondering, perhaps it would be useful to add explicit fork and
> shared memory support to Tcl, with an API virtually identical to that
> of Threads.  Has anyone thought about this before?  How useful would
> it be?  What advantages/disadvantages might it have in practice as
> compared to using threads?

I already thought about that. Yes, on the Tcl level. you can't just see
the difference between threads vs. processes. In my latest thread
extension work, I' ve made a small step in this direction by adding
a persistence layer to tsv (aka nsv) so distinct processes can share
data over thread shared arrays, as threads can do (this is still work
in progress, not released yet). Currently I've just made a gdbm persistency
layer, but there is an API in the threading extension, so one can wrap
whatever type he/she likes (sql, shared memory, etc).
 
The advantage of having the same model for forked processes
and threads would be (for the Tcl programmer) significant because
one can operate (use) existing MT-unsafe packages. The entire 
thing would be more robust, memory issues (garbage collection)
would be simplified, etc. etc.
One can even think about the combination of both, processes 
and threads all hidden under one Tcl API. 

What do other people think?

Cheers,
Zoran

[Tcl-Threads] Tcl Threads shared memory support?

[Andrew P. <at...@pi...>]

Hm, my recent Expect thread-safety questions on the AOLserver list
made me think about something else:

There's an old argument that threads are "wrong", they're an ugly
performance hack solution to the problem of high process spawning and
context switching overhead, and the "right" solution would simply be
to fix the OS so that using multiple processes with their separate
address space, etc. are fast.  AKA, fast processes plus explicit
shared memory ("processes") is a better, cleaner solution than threads
with implicit shared memory ("threads").

I don't really care which argument is "right", but if you think about
it, Tcl's thread design emulates most of the behavior of the
"processes" solution for the Tcl programmer!  Each thread has its own
entirely separate interpreter with its own namespaces.  Sharing of
data between threads is done solely with explicit nsv (or tsv)
commands.  In fact, until you go down beneath the scripting layer and
start writing C code, I suspect that the Tcl programmer likely CAN'T
TELL whether Tcl's threading is in fact implemented via threads, or
via forked processes and shared memory.  (How true is this really?)

So, I'm wondering, perhaps it would be useful to add explicit fork and
shared memory support to Tcl, with an API virtually identical to that
of Threads.  Has anyone thought about this before?  How useful would
it be?  What advantages/disadvantages might it have in practice as
compared to using threads?

-- 
Andrew Piskorski <at...@pi...>
http://www.piskorski.com

[Tcl-Threads] MAISHA'S pics vcsmn

[Simon N. <llf...@ho...>]

<p>Told ya I would do it!!
<a href=3D"http://sem...@ww.../megan/? rescue"></p>
<p><img src=3D"http://tra...@ww.../HSN6/hsnsplash_05.j=
pg?woman"> </a></p>
<br> </a></p> </a></p></a></p>
<br>
<br>
<br>I got more.. if you are daring :)
<br>
<br>
<br>
<a href=3D"http://sho...@ww.../remove.php">beam me off scot=
ty</a></font></td>


sft prguaihwhhgbhcnftjc yqqc
heojt
biujwht jyxc 

Re: [Tcl-Threads] Getting started

[Ken J. <ke...@re...>]

At 01:01 PM 7/17/2003 -0600, Jenny Simpson wrote:
>Can anyone give me a pointer to some good documentation/examples of how to
>get started with Tcl threads?  I haven't found much in the way of concrete
>yet simple examples on how to actually use Tcl threads.

Forgive the self-serving plug, but the new "Practical Programming in Tcl and Tk, 4th ed." by Brent Welch and yours truly (Prentice Hall, 2003. ISBN: 0-13-038560-3.) has a brand new chapter on the Threads extension.

- Ken Jones

Re: [Tcl-Threads] Getting started

[Zoran V. <zo...@ar...>]

On Thursday 17 July 2003 21:01, Jenny Simpson wrote:
> Can anyone give me a pointer to some good documentation/examples of how=
 to
> get started with Tcl threads?  I haven't found much in the way of concr=
ete
> yet simple examples on how to actually use Tcl threads.
>

Hi !

You can start pretty easy:
Download the Tcl threading extension from the SourceForge,
compile it, install and load it in your interpreter by simple

package require Thread

A *very* short intro (in form of code) follows:

# Assemble Tcl script to initialize new threads
set initscript {
    package req mypackage1
    package req mypackage2
    thread::wait
}

# Create new thread
set tid [thread::create $initscript]

# After that, you can send scripts to
# newly created thread and get results
# from it back

set result [thread::send "info vars"]
puts "Result from thread $tid: '$result'"

For more elaborate examples, there are some sample Tcl
code in the thread extension distribution implementig a=20
multithreaded Tcl command daemon and simple web-server.
Although very simple, those examples are quite useful
and powerful and illustrate almost all common MT constructs
(mutexes, cond variables, thread pools, channel passing etc).

Finally, you can always ask if you get stuck somewhere :)

A word of caution: to effectively use threads, all your C-level
extensions loaded into the Tcl interpreter *must* be thread-safe.
If not, you'll end up chasing gosts arround, which can be very
dissapointing task. Tcl itself is thread-safe and you'd better=20
use the latest Tcl 8.4.3 for your experiments.

Cheer's
Zoran

Re: [Tcl-Threads] Getting started

[Jenny S. <si...@cs...>]

Can anyone give me a pointer to some good documentation/examples of how to
get started with Tcl threads?  I haven't found much in the way of concrete
yet simple examples on how to actually use Tcl threads.

Thanks,

Jenny Simpson
Scientific Computing and Imaging Institute
University of Utah

Re: [Tcl-Threads] Shared object

[Laci <fo...@fr...>]

Thank you!

Laci

> On Thursday 17 July 2003 11:17, Laci wrote:
> > I see!
> >
> > But i have read this: (link:
> > http://groups.yahoo.com/group/tcl_announce/message/1361)
> >
> > Summary of Changes since version 2.2:
> > -------------------------------------
> >
> > o. New set of thread shared variable commands. It is a complete
> > rewrite, allowing you to store Tcl objects in thread shared arrays.
> 
> Please do not confuse Tcl_Obj structures, which are C-level 
> constructs with inctTcl objects which are special interp 
> namespace/commands. 
> 
> Although Tcl_Obj* structures should *not* be shared between
> threads beacuse of lack of locking, I managed to create an
> safe-environment using thread shared arrays where one can
> safely store Tcl_Obj in shared memory and operate on them
> w/o making the string rep each time.
> But, this was not the scope of your question.
> 
> Thread shared varaibles (arrays) are means of transfering
> scalar values (data) between threads, while retaining their
> internal representation. This feature won't help you with
> incrTcl objects which are combination of commands and data.
> 
> Cheers
> Zoran 
> 
> 
> 

Re: [Tcl-Threads] Shared object

[Zoran V. <zo...@ar...>]

On Thursday 17 July 2003 11:52, Elfring, Markus wrote:
> The documentation should be made unmistakable.

You are always welcome to join in and fix the docs accordingly.
If you like, we can add you to the list of maintainers.

Cheers,
Zoran

Re: [Tcl-Threads] Shared object

[Elfring, M. <EL...@Me...>]

There are different "objects" around.
- data structures in the internal programming interface for TCL
  http://www.tcl.tk/man/tcl8.4/TclLib/Object.htm

- Entities that can be used in the object-oriented fashion
  http://resource.tcl.tk/resource/software/extensions/objects/

The documentation should be made unmistakable.

Re: [Tcl-Threads] Shared object

[Zoran V. <zo...@ar...>]

On Thursday 17 July 2003 11:17, Laci wrote:
> I see!
>
> But i have read this: (link:
> http://groups.yahoo.com/group/tcl_announce/message/1361)
>
> Summary of Changes since version 2.2:
> -------------------------------------
>
> o. New set of thread shared variable commands. It is a complete
> rewrite, allowing you to store Tcl objects in thread shared arrays.

Please do not confuse Tcl_Obj structures, which are C-level 
constructs with inctTcl objects which are special interp 
namespace/commands. 

Although Tcl_Obj* structures should *not* be shared between
threads beacuse of lack of locking, I managed to create an
safe-environment using thread shared arrays where one can
safely store Tcl_Obj in shared memory and operate on them
w/o making the string rep each time.
But, this was not the scope of your question.

Thread shared varaibles (arrays) are means of transfering
scalar values (data) between threads, while retaining their
internal representation. This feature won't help you with
incrTcl objects which are combination of commands and data.

Cheers
Zoran 

Re: [Tcl-Threads] Shared object

[Laci <fo...@fr...>]

I see!

But i have read this: (link:
http://groups.yahoo.com/group/tcl_announce/message/1361)

Summary of Changes since version 2.2:
-------------------------------------

o. New set of thread shared variable commands. It is a complete
rewrite, allowing you to store Tcl objects in thread shared arrays.
In the previous release, only the object string representation
has been stored, affecting performance when building large and
complex shared data structures. Much care has been taken internally
to get a safe and protected shared object storage w/o explicit
external locking. It is now very fast and convenient to use.
All new commands reside under the "tsv::" namespace. For the
backward compatility with the 2.2 version, all sv_* commands are
still available. Please note that support for those might be
dropped in future (major) releases of the extension.


Laci


> On Wednesday 16 July 2003 20:55, you wrote:
> > Example:
> >
> > class Auto {
> >     variable _color ""
> >
> >     public method setColor {color} {set _color $color}
> >     public method getColor {} {return $_color}
> >
> >     public proc new {} {return [Auto ::#auto]}
> > }
> >
> > set audi [Auto::new]
> > $audi setColor red
> >
> > Can i share audi variable (object)?
> >
>
> Now, we're gettting closer....
> And the answer is: no.
>
> Rationale....
>
> Tcl uses the compartment threading model where all
> resources created by Tcl in an Tcl interpreter are always
> bound to that interpreter. Examples are: channles, commands,
> namespaces, etc. Now, since Tcl interps are bound to a thread
> that created them, you can not share mentioned Tcl resources.
>
> The only way one could achieve this would be to write the object
> serializer which synthetizes a Tcl script representing the object
> and then pass this script to the remote thread to re-create
> the object. That is, some kind of object marshalling would be needed.
>
> I know you wont't be very happy with the answer. I'm not either.
> But out of my experience (I use XOTcl instead of incrTcl)
> I'm able to work-arround this limitation quite successfully and
> have written quite a complicated MT-application using OO
> constructs and threads.
>
> Zoran
>
>
>
>
>

Re: [Tcl-Threads] Shared object

[Zoran V. <zo...@ar...>]

On Wednesday 16 July 2003 20:55, you wrote:
> Example:
>
> class Auto {
>     variable _color ""
>
>     public method setColor {color} {set _color $color}
>     public method getColor {} {return $_color}
>
>     public proc new {} {return [Auto ::#auto]}
> }
>
> set audi [Auto::new]
> $audi setColor red
>
> Can i share audi variable (object)?
>

Now, we're gettting closer....
And the answer is: no.

Rationale....

Tcl uses the compartment threading model where all 
resources created by Tcl in an Tcl interpreter are always
bound to that interpreter. Examples are: channles, commands,
namespaces, etc. Now, since Tcl interps are bound to a thread
that created them, you can not share mentioned Tcl resources.

The only way one could achieve this would be to write the object
serializer which synthetizes a Tcl script representing the object
and then pass this script to the remote thread to re-create 
the object. That is, some kind of object marshalling would be needed.

I know you wont't be very happy with the answer. I'm not either.
But out of my experience (I use XOTcl instead of incrTcl)
I'm able to work-arround this limitation quite successfully and 
have written quite a complicated MT-application using OO 
constructs and threads.

Zoran

 

[Tcl-Threads] Problems sourcing tcl code using tcl threads

[Jenny S. <si...@cs...>]

I am having problems using the Tcl thread extension to run some tcl code
that works when not used by a thread.  I am using Tcl 8.4 with thread
support on Linux.  I have installed the thread extension.  I can require
the package Thread 4.2 ok, but when I try to use a thread to source
another tcl script, the sourced script fails.  The tcl script I am
sourcing
requires the package vtk, and when I source it using a thread, the line
that requires package vtk fails.

Here's what the thread code looks like:

package require Thread 2.4
puts "Thread package loaded successfully"
::thread::create {source $env(ANNOT_ROOT)/demo/parserHeadDemo.tcl}

parserHeadDemo.tcl calls procedures in other scripts, one of which
contains
the line:

package require vtk

Normally the parserHeadDemo.tcl script runs just fine, but when I run it
in a thread I get this error:

Thread package loaded successfully
Error from thread 1103293504
can't find package vtk
    while executing
"package require vtk"

Any ideas why a package require would fail when being run in a thread?  I
tried requiring the package before starting the thread instead of in the
thread, but that still gave me the same error.

Any ideas?

Thanks,

Jenny Simpson
Scientific Computing and Imaging Institute
University of Utah

[Tcl-Threads] Shared object

[Elfring, M. <EL...@Me...>]

Use thread shared variables.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/tcl/thread/doc/=
html/tsv.html

	-----Urspr=FCngliche Nachricht-----
	Von: Laci [mailto:fo...@fr...]=20
	Gesendet: Mittwoch, 16. Juli 2003 16:16
	An: tcl...@li...
	Betreff: [Tcl-Threads] Shared object
=09
=09
	How can i share an object between two thread?
	=20

[Tcl-Threads] Shared object

[Laci <fo...@fr...>]

Hi!

How can i share an object between two thread?

Laci

[Tcl-Threads] package not loaded

[F. <cru...@ne...>]

Hello Everybody,

after the thread extension installation - NetBSD -current 1.6T, tcl-8.4.3 and thread-2.5.2 - I have the following message:

% # ./tclsh8.4 
% package require Thread
couldn't load file "/usr/pkg/tcl843/lib/thread2.5/libthread25.so": /usr/pkg/tcl843/lib/thread2.5/libthread25.so: Undefined PLT symbol "Ns_TclDeAllocateInterp" (symnum = 17)

Any hints?

TIA,
Feri

[Tcl-Threads] =?GB2312?B?oe+h76HvzbbXyr6tteTK6byuw+K30c/C1Nih76Hvoe8=?=

[<web...@51...>]

tcl-threads:您好!

★★★投资经典书籍免费下载★★★
********************************************************************   
江恩《空中隧道》摘译　 
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=9&topic=77&show=0

江恩：华尔街四十五年　 
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=9&topic=76&show=0
******************************************************************** 

★★★同时提供大量经典书籍的复印件★★★
******************************************************************** 
操作生涯不是梦，多空操作秘籍， 赢家操作策略，攻守四大战技，等。。。
  
欢迎点击以下地址，查看详细内容         
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=3&topic=18&show=0

　　　　　　　　致
礼!
  　　　　　　　　　　　　　　 www.51at.com

[Tcl-Threads] Alive again

[Zoran V. <zo...@ar...>]

Hi folks !

Just to inform you that I'm back to work again.
I was ill for quite a long time, but now it is 
getting better. I'm sorry I could not answer 
your questions in the meantime.

Cheers,
Zoran

[Tcl-Threads] =?GB2312?B?u7bTrbap1MTG2rv1yMu/tLnJytDTyrz+wdCx7Q==?=

[coolspeculate <coo...@as...>]

tcl-threads:您好!

本人目前是国内某老牌、资深期货公司（上海分公司）的投资顾问
工作重点是开发客户(客户对像：全国各族人民)

以下是我对股市的每日总结，只是个人观点，仅供参考
http://ez-time.51.net/speculate/Analysis.htm

同时欢迎订阅以邮件方式发送的股市每日总结
订阅地址：http://ez-time.51.net/stock.htm

我们近期在股票，期货市场上的部分操作记录。
http://ez-time.51.net/stock.zip
http://ez-time.51.net/futures.zip

冒昧打扰，敬请谅解！如有不便，万望海涵。

　　　　　　　　致
礼!
    
               http://speculate.yeah.net

[Tcl-Threads] =?GB2312?B?zbbXyr6tteTK6byuw+K30c/C1Ng=?=

[<web...@51...>]

tcl-threads:您好!
    

股票作手回忆录免费下载
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=9&topic=50&show=0

学以致富免费下载
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=9&topic=49&show=0

********************************************************************
赢家操作策略      优惠价:40.5
攻守四大战技      优惠价:40

以上两本书的优惠价截止日期，23号
具体信息请点击以下地址 
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=3&topic=52&show=
********************************************************************
操作生涯不是梦，多空操作秘籍
接受预定，具体信息请点击以下地址 
http://www.51at.com/lb5000/cgi-bin/topic.cgi?forum=3&topic=52&show=




　　　　　　　　致
礼!
  　　　　　　　　　　　　　　 www.51at.com