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

[Tcl-Threads] Sample code for

[Kay <ko...@gm...>]

Hi,

I just started with Tcl/Tk. I want to use the Tk buttons to change some
variables of my application. The problem is that I have another windowing
system to draw stuff, so I guess I want to do Tk_Main(argc, argv,
Tcl_AppInit); in another thread. Could someone point to me as to how I
should do that?

thanks,
-Kay

Re: [Tcl-Threads] Problem with thread::transfer and TclHttpd

[Rusty B. <me...@ru...>]

I upgraded to 2.6.4, and now the after idle trick works for me.  Thanks 
for the tip.

Rusty

Rusty Brooks wrote:
> I'm using Threads 2.4, the man pages don't mention what you have below.  
> Also, it does not appear to work, in the case of 2.4 (I get the same 
> error as before)s.  I'm going to see if I can upgrade to 2.6 and see if 
> that helps.
>
> Jeff Hobbs wrote:
>   
>> Rusty Brooks wrote:
>>     
>>> I was doing some experiments with changing how TclHttpd handles 
>>> connections.  Namely, I want to "hand off" the newly opened socket to 
>>> a new thread instead of handling a lot of the housekeeping in the 
>>> main thread.  Sort of an experiment I'm working on.
>>>
>>> However, if I try to use thread::transfer with the socket that is 
>>> opened via the socket -server handler, I get this error:
>>>
>>> "channel is shared"
>>>
>>> This is the error you get if the channel is in use by a child interp, 
>>> or, I gather, it has a fileevent or something like that on it.  
>>> Looking through the tclhttpd code, I don't see anything like this (no 
>>> fileevent, there ARE no child interps...) so I am at a loss to figure 
>>> out why I can't transfer this socket.
>>>
>>> Any thoughts on the problem, or is there a good method for me to 
>>> determine what the root cause of the problem is?
>>>       
>> Did you follow the thread::transfer docs which hint at a possible 
>> solution to this problem?
>>
>> """
>> Due to the internal Tcl core implementation and the restriction on
>> transferring shared channels, one has to take extra measures when
>> transferring socket channels created by accepting the connection
>> out of the \fBsocket\fR commands callback procedures:
>> .nf
>>     socket -server _Accept 2200
>>     proc _Accept {s ipaddr port} {
>>         after idle [list Accept $s $ipaddr $port]
>>     }
>>     proc Accept {s ipaddr port} {
>>         set tid [thread::create]
>>         thread::transfer $tid $s
>>     }
>> .fi
>> """
>>
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Tcl-Threads mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-threads
>   

Re: [Tcl-Threads] Problem with thread::transfer and TclHttpd

[Rusty B. <me...@ru...>]

I'm using Threads 2.4, the man pages don't mention what you have below.  
Also, it does not appear to work, in the case of 2.4 (I get the same 
error as before)s.  I'm going to see if I can upgrade to 2.6 and see if 
that helps.

Jeff Hobbs wrote:
> Rusty Brooks wrote:
>> I was doing some experiments with changing how TclHttpd handles 
>> connections.  Namely, I want to "hand off" the newly opened socket to 
>> a new thread instead of handling a lot of the housekeeping in the 
>> main thread.  Sort of an experiment I'm working on.
>>
>> However, if I try to use thread::transfer with the socket that is 
>> opened via the socket -server handler, I get this error:
>>
>> "channel is shared"
>>
>> This is the error you get if the channel is in use by a child interp, 
>> or, I gather, it has a fileevent or something like that on it.  
>> Looking through the tclhttpd code, I don't see anything like this (no 
>> fileevent, there ARE no child interps...) so I am at a loss to figure 
>> out why I can't transfer this socket.
>>
>> Any thoughts on the problem, or is there a good method for me to 
>> determine what the root cause of the problem is?
>
> Did you follow the thread::transfer docs which hint at a possible 
> solution to this problem?
>
> """
> Due to the internal Tcl core implementation and the restriction on
> transferring shared channels, one has to take extra measures when
> transferring socket channels created by accepting the connection
> out of the \fBsocket\fR commands callback procedures:
> .nf
>     socket -server _Accept 2200
>     proc _Accept {s ipaddr port} {
>         after idle [list Accept $s $ipaddr $port]
>     }
>     proc Accept {s ipaddr port} {
>         set tid [thread::create]
>         thread::transfer $tid $s
>     }
> .fi
> """
>

Re: [Tcl-Threads] Problem with thread::transfer and TclHttpd

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

Rusty Brooks wrote:
> I was doing some experiments with changing how TclHttpd handles 
> connections.  Namely, I want to "hand off" the newly opened socket to a 
> new thread instead of handling a lot of the housekeeping in the main 
> thread.  Sort of an experiment I'm working on.
> 
> However, if I try to use thread::transfer with the socket that is opened 
> via the socket -server handler, I get this error:
> 
> "channel is shared"
> 
> This is the error you get if the channel is in use by a child interp, 
> or, I gather, it has a fileevent or something like that on it.  Looking 
> through the tclhttpd code, I don't see anything like this (no fileevent, 
> there ARE no child interps...) so I am at a loss to figure out why I 
> can't transfer this socket.
> 
> Any thoughts on the problem, or is there a good method for me to 
> determine what the root cause of the problem is?

Did you follow the thread::transfer docs which hint at a possible 
solution to this problem?

"""
Due to the internal Tcl core implementation and the restriction on
transferring shared channels, one has to take extra measures when
transferring socket channels created by accepting the connection
out of the \fBsocket\fR commands callback procedures:
.nf
     socket -server _Accept 2200
     proc _Accept {s ipaddr port} {
         after idle [list Accept $s $ipaddr $port]
     }
     proc Accept {s ipaddr port} {
         set tid [thread::create]
         thread::transfer $tid $s
     }
.fi
"""

-- 
   Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/

[Tcl-Threads] Problem with thread::transfer and TclHttpd

[Rusty B. <me...@ru...>]

I was doing some experiments with changing how TclHttpd handles 
connections.  Namely, I want to "hand off" the newly opened socket to a 
new thread instead of handling a lot of the housekeeping in the main 
thread.  Sort of an experiment I'm working on.

However, if I try to use thread::transfer with the socket that is opened 
via the socket -server handler, I get this error:

"channel is shared"

This is the error you get if the channel is in use by a child interp, 
or, I gather, it has a fileevent or something like that on it.  Looking 
through the tclhttpd code, I don't see anything like this (no fileevent, 
there ARE no child interps...) so I am at a loss to figure out why I 
can't transfer this socket.

Any thoughts on the problem, or is there a good method for me to 
determine what the root cause of the problem is?

I even looked into the tcl code, and the error comes down to checking 
the number of references on a channel, and if it's more than 1, not 
allowing the transfer.  I did not really look far enough to find out 
where the references could be coming from.

Rusty

Re: [Tcl-Threads] TCL-Expect-Threads Dilemma

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

Hi Andy,

You have to explicitly share channels between threads, but std channels are
excluded (as noted in the docs for thread::transfer) because they are shared
amongst the main thread intpreters.

The Expect for Windows source code is open source.  If you would like to
verify and improve its thread-safety, you are welcome to do so.  Aside from
Tcl's regular pipe functionality (which works for a large variety of cases
that people use Expect for, but not all), I'm not aware of alternatives.

Jeff

Andy Brown wrote:
> Jeff:
> 
> Thanks for the info.  We are running on Windows.  Since 
> Expect isn't guaranteed thread-safe on any platform it is 
> probably best we not use it. Do you know of a PuTTY/Plink TCL 
> wrapper?  I'm assuming one doesn't exist because most people 
> would just use Plink with Expect.  If not, I guess I will 
> have to dive in and see if I can create one.
> 
> I understand the one set of standard channels per 
> application.  What I don't understand (and it is me being not 
> familiar with TCL's design) is that if I create and register 
> the standard channels in a main thread am I having trouble 
> using them in my separate dedicated interpreter threads?  
> Since we will probably not be able to use Expect in this 
> design the point is moot aside from my own curiosity.
> 
> Thanks again,
> Andy
> 
> -----Original Message-----
> From: Jeff Hobbs [mailto:je...@ac...] 
> Sent: Tuesday, January 30, 2007 6:58 PM
> To: 'Andy Brown'; tcl...@li...
> Subject: RE: [Tcl-Threads] TCL-Expect-Threads Dilemma
> 
> Hi Andy,
> 
> You are mixing a few things here without being quite clear on 
> design.  Are you talking about Expect for Windows and/or Unix?
> 
> In the case of unix, I can say that without a doubt, Expect 
> has never been made thread-safe there.  The Windows port may 
> be a little better off, but has also never been verified for 
> any level of thread-safety.
> 
> As to the channels issue, if you want to work with standard 
> channels, there really should be only one set per 
> application.  That's kind of an OS-level thing that one must adapt to.
> 
> Jeff
> 
> Andy Brown wrote:
> > We have an existing C test executive that runs tests on
> > multiple devices under test (DUT) in parallel.  Each device 
> > is tested in its own thread and each test is a stand-alone 
> > TCL script that makes the measurement and logs the results.  
> > We've used this simple architecture for years without issue. 
> > The test executive creates a dedicated interpreter-thread 
> > pair and makes sure both are only used with one another.  Up 
> > until now all of our communication with the DUT has been 
> > through SNMP, more specifically NET-SNMP, which works great 
> > under TCL.  We are now working with some DUTs that require 
> > telnet.  For that we would love to use Expect.  However we 
> > have run into an issue we can't seem to get around.
> > 
> > Our test executive is a Windows GUI application so by default
> > there are no standard channels.  By working through the Tk 
> > code I was able to modify our test executive to create and 
> > register channels to use as the standard channels.  This 
> > works only for 1 interpreter and only if I create and 
> > register the channels in the thread that that interpreter 
> > belongs to.  So from my understanding (which may be in error) 
> > I'm kind of stuck here:
> >      - there can only be 1 set of standard channels for an 
> > application that is shared by all threads of that process
> >      - the channels must be created and registered in the 
> > thread for the interpreter they will be used with
> > 
> > I tried creating the channels and calling Tcl_SetStdChannel
> > in the main thread, then in each interpreter thread calling 
> > Tcl_GetStdChannel but this did not work.  For now I got it to 
> > work by creating a single interpreter thread with a master 
> > interpreter in it.  Then instead of creating new 
> > thread/interpreter pairs for each DUT, I create a slave 
> > interpreter inside the master that also runs in the master 
> > interpreter's thread.  While this allows each interpreter to 
> > successfully run Expect, it greatly limits the parallelism of 
> > the test executive and drastically slows down the throughput 
> > of the test station.
> > 
> > Anyone successful at getting Expect to run in multiple
> > threads in parallel?
> > 
> > Andy
> 
> 
> 

Re: [Tcl-Threads] TCL-Expect-Threads Dilemma

[Andy B. <ab...@da...>]

Jeff:

Thanks for the info.  We are running on Windows.  Since Expect isn't
guaranteed thread-safe on any platform it is probably best we not use it.
Do you know of a PuTTY/Plink TCL wrapper?  I'm assuming one doesn't exist
because most people would just use Plink with Expect.  If not, I guess I
will have to dive in and see if I can create one.

I understand the one set of standard channels per application.  What I don't
understand (and it is me being not familiar with TCL's design) is that if I
create and register the standard channels in a main thread am I having
trouble using them in my separate dedicated interpreter threads?  Since we
will probably not be able to use Expect in this design the point is moot
aside from my own curiosity.

Thanks again,
Andy

-----Original Message-----
From: Jeff Hobbs [mailto:je...@ac...] 
Sent: Tuesday, January 30, 2007 6:58 PM
To: 'Andy Brown'; tcl...@li...
Subject: RE: [Tcl-Threads] TCL-Expect-Threads Dilemma

Hi Andy,

You are mixing a few things here without being quite clear on design.  Are
you
talking about Expect for Windows and/or Unix?

In the case of unix, I can say that without a doubt, Expect has never been
made thread-safe there.  The Windows port may be a little better off, but
has
also never been verified for any level of thread-safety.

As to the channels issue, if you want to work with standard channels, there
really should be only one set per application.  That's kind of an OS-level
thing that one must adapt to.

Jeff

Andy Brown wrote:
> We have an existing C test executive that runs tests on 
> multiple devices under test (DUT) in parallel.  Each device 
> is tested in its own thread and each test is a stand-alone 
> TCL script that makes the measurement and logs the results.  
> We've used this simple architecture for years without issue. 
> The test executive creates a dedicated interpreter-thread 
> pair and makes sure both are only used with one another.  Up 
> until now all of our communication with the DUT has been 
> through SNMP, more specifically NET-SNMP, which works great 
> under TCL.  We are now working with some DUTs that require 
> telnet.  For that we would love to use Expect.  However we 
> have run into an issue we can't seem to get around.
> 
> Our test executive is a Windows GUI application so by default 
> there are no standard channels.  By working through the Tk 
> code I was able to modify our test executive to create and 
> register channels to use as the standard channels.  This 
> works only for 1 interpreter and only if I create and 
> register the channels in the thread that that interpreter 
> belongs to.  So from my understanding (which may be in error) 
> I'm kind of stuck here:
>      - there can only be 1 set of standard channels for an 
> application that is shared by all threads of that process
>      - the channels must be created and registered in the 
> thread for the interpreter they will be used with
> 
> I tried creating the channels and calling Tcl_SetStdChannel 
> in the main thread, then in each interpreter thread calling 
> Tcl_GetStdChannel but this did not work.  For now I got it to 
> work by creating a single interpreter thread with a master 
> interpreter in it.  Then instead of creating new 
> thread/interpreter pairs for each DUT, I create a slave 
> interpreter inside the master that also runs in the master 
> interpreter's thread.  While this allows each interpreter to 
> successfully run Expect, it greatly limits the parallelism of 
> the test executive and drastically slows down the throughput 
> of the test station.
> 
> Anyone successful at getting Expect to run in multiple 
> threads in parallel?
> 
> Andy

Re: [Tcl-Threads] TCL-Expect-Threads Dilemma

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

Hi Andy,

You are mixing a few things here without being quite clear on design.  =
Are you
talking about Expect for Windows and/or Unix?

In the case of unix, I can say that without a doubt, Expect has never =
been
made thread-safe there.  The Windows port may be a little better off, =
but has
also never been verified for any level of thread-safety.

As to the channels issue, if you want to work with standard channels, =
there
really should be only one set per application.  That's kind of an =
OS-level
thing that one must adapt to.

Jeff

Andy Brown wrote:
> We have an existing C test executive that runs tests on=20
> multiple devices under test (DUT) in parallel.  Each device=20
> is tested in its own thread and each test is a stand-alone=20
> TCL script that makes the measurement and logs the results. =20
> We've used this simple architecture for years without issue.=20
> The test executive creates a dedicated interpreter-thread=20
> pair and makes sure both are only used with one another.  Up=20
> until now all of our communication with the DUT has been=20
> through SNMP, more specifically NET-SNMP, which works great=20
> under TCL.  We are now working with some DUTs that require=20
> telnet.  For that we would love to use Expect.  However we=20
> have run into an issue we can't seem to get around.
>=20
> Our test executive is a Windows GUI application so by default=20
> there are no standard channels.  By working through the Tk=20
> code I was able to modify our test executive to create and=20
> register channels to use as the standard channels.  This=20
> works only for 1 interpreter and only if I create and=20
> register the channels in the thread that that interpreter=20
> belongs to.  So from my understanding (which may be in error)=20
> I'm kind of stuck here:
>      - there can only be 1 set of standard channels for an=20
> application that is shared by all threads of that process
>      - the channels must be created and registered in the=20
> thread for the interpreter they will be used with
>=20
> I tried creating the channels and calling Tcl_SetStdChannel=20
> in the main thread, then in each interpreter thread calling=20
> Tcl_GetStdChannel but this did not work.  For now I got it to=20
> work by creating a single interpreter thread with a master=20
> interpreter in it.  Then instead of creating new=20
> thread/interpreter pairs for each DUT, I create a slave=20
> interpreter inside the master that also runs in the master=20
> interpreter's thread.  While this allows each interpreter to=20
> successfully run Expect, it greatly limits the parallelism of=20
> the test executive and drastically slows down the throughput=20
> of the test station.
>=20
> Anyone successful at getting Expect to run in multiple=20
> threads in parallel?
>=20
> Andy

[Tcl-Threads] TCL-Expect-Threads Dilemma

[Andy B. <ab...@da...>]

We have an existing C test executive that runs tests on multiple devices
under test (DUT) in parallel.  Each device is tested in its own thread and
each test is a stand-alone TCL script that makes the measurement and logs
the results.  We've used this simple architecture for years without issue.
The test executive creates a dedicated interpreter-thread pair and makes
sure both are only used with one another.  Up until now all of our
communication with the DUT has been through SNMP, more specifically
NET-SNMP, which works great under TCL.  We are now working with some DUTs
that require telnet.  For that we would love to use Expect.  However we have
run into an issue we can't seem to get around.

Our test executive is a Windows GUI application so by default there are no
standard channels.  By working through the Tk code I was able to modify our
test executive to create and register channels to use as the standard
channels.  This works only for 1 interpreter and only if I create and
register the channels in the thread that that interpreter belongs to.  So
from my understanding (which may be in error) I'm kind of stuck here:
     - there can only be 1 set of standard channels for an application that
is shared by all threads of that process
     - the channels must be created and registered in the thread for the
interpreter they will be used with

I tried creating the channels and calling Tcl_SetStdChannel in the main
thread, then in each interpreter thread calling Tcl_GetStdChannel but this
did not work.  For now I got it to work by creating a single interpreter
thread with a master interpreter in it.  Then instead of creating new
thread/interpreter pairs for each DUT, I create a slave interpreter inside
the master that also runs in the master interpreter's thread.  While this
allows each interpreter to successfully run Expect, it greatly limits the
parallelism of the test executive and drastically slows down the throughput
of the test station.

Anyone successful at getting Expect to run in multiple threads in parallel?

Andy

Re: [Tcl-Threads] TCL 8.3.4 crashes on a linux when compiled with SMPsupport

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

You still don't note whether you are violating the basic principles of
single-threaded access to any interp.  Of course the SMP will expose real MP
errors, because that is when you can finally have 2 threads running
simultaneously.  Using threads on single CPU machines has very limited use.

Jeff

rajh wrote:
> Yes, I have compiled the code with --enable-threads and also 
> I am creating a new interpreter for each thread. I dont see 
> any crashes when I run it on a single processor system. I can 
> run as many threads as I want and it runs perfectly fine. I 
> have run multiple threads over a week with no crash on a 
> single processor.
> 
> However, if I run it on a dual processor system with SMP 
> enabled, it crashes. Its something to do with the multi 
> processors and I have no idea how to debug this.
> 
> 
> 
> Jeff Hobbs wrote:
> > 
> > Raj wrote:
> >> I am using TCL interpreter for doing some parsing for
> >> my application. I have multiple threads using the TCL library 
> >> simultaneously. Everything seems to work fine when I compile my linux 
> >> code with non SMP support or run it on a single CPU. However TCL 
> >> crashes with the trace below when I compile linux with SMP support 
> >> and run the application on a dual proc system. I am using
> >> TCL 8.3.4 right now and am wondering if there is any
> >> known issue which has been fixed or is pending. Here's
> >> the trace of the crash. Looks like the stack is
> >> corrupted but I get this exact trace consistently
> >> everytime TCL crashes.
> > 
> > Did you compile Tcl with --enable-threads?  That will make it 
> > thread-safe, but you should still not access a single interpreter from 
> > multiple threads simultaneously (without mutex locking).

Re: [Tcl-Threads] TCL 8.3.4 crashes on a linux when compiled with SMPsupport

[rajh <raj...@ya...>]

Yes, I have compiled the code with --enable-threads and also I am creating a
new interpreter for each thread. I dont see any crashes when I run it on a
single processor system. I can run as many threads as I want and it runs
perfectly fine. I have run multiple threads over a week with no crash on a
single processor.

However, if I run it on a dual processor system with SMP enabled, it
crashes. Its something to do with the multi processors and I have no idea
how to debug this.



Jeff Hobbs wrote:
> 
> Raj wrote:
>> I am using TCL interpreter for doing some parsing for
>> my application. I have multiple threads using the TCL
>> library simultaneously. Everything seems to work fine
>> when I compile my linux code with non SMP support or
>> run it on a single CPU. However TCL crashes with the
>> trace below when I compile linux with SMP support and
>> run the application on a dual proc system. I am using
>> TCL 8.3.4 right now and am wondering if there is any
>> known issue which has been fixed or is pending. Here's
>> the trace of the crash. Looks like the stack is
>> corrupted but I get this exact trace consistently
>> everytime TCL crashes.
> 
> Did you compile Tcl with --enable-threads?  That will make it thread-safe,
> but
> you should still not access a single interpreter from multiple threads
> simultaneously (without mutex locking).
> 
> Jeff
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tcl-Threads mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-threads
> 
> 

-- 
View this message in context: http://www.nabble.com/TCL-8.3.4-crashes-on-a-linux-when-compiled-with-SMP-support-tf2741215.html#a7688974
Sent from the tcl-threads mailing list archive at Nabble.com.

Re: [Tcl-Threads] TCL 8.3.4 crashes on a linux when compiled with SMPsupport

[<ke...@cr...>]

je...@ac... said:
> Did you compile Tcl with --enable-threads?  That will make it
> thread-safe, but you should still not access a single interpreter from
> multiple threads simultaneously (without mutex locking).

Or even *with* it - the interpreter's data can easily be polluted with
thread-specific data, particularly when the zippy allocator is in use.
--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tcl-Threads] TCL 8.3.4 crashes on a linux when compiled with SMPsupport

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

Raj wrote:
> I am using TCL interpreter for doing some parsing for
> my application. I have multiple threads using the TCL
> library simultaneously. Everything seems to work fine
> when I compile my linux code with non SMP support or
> run it on a single CPU. However TCL crashes with the
> trace below when I compile linux with SMP support and
> run the application on a dual proc system. I am using
> TCL 8.3.4 right now and am wondering if there is any
> known issue which has been fixed or is pending. Here's
> the trace of the crash. Looks like the stack is
> corrupted but I get this exact trace consistently
> everytime TCL crashes.

Did you compile Tcl with --enable-threads?  That will make it =
thread-safe, but
you should still not access a single interpreter from multiple threads
simultaneously (without mutex locking).

Jeff

[Tcl-Threads] TCL 8.3.4 crashes on a linux when compiled with SMP support

[Raj <raj...@ya...>]

I am using TCL interpreter for doing some parsing for
my application. I have multiple threads using the TCL
library simultaneously. Everything seems to work fine
when I compile my linux code with non SMP support or
run it on a single CPU. However TCL crashes with the
trace below when I compile linux with SMP support and
run the application on a dual proc system. I am using
TCL 8.3.4 right now and am wondering if there is any
known issue which has been fixed or is pending. Here's
the trace of the crash. Looks like the stack is
corrupted but I get this exact trace consistently
everytime TCL crashes.

#0  0x7efff0e4 in ?? ()
#1  <signal handler called>
#2  0x2b6ec9e4 in __syscall_rt_sigsuspend () at
<stdin>:2
#3  0x2b6eb090 in __sigsuspend (set=0x7efff390)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
#4  0x2ab4accc in __pthread_wait_for_restart_signal
(self=0x7efffbe0)
    at pthread.c:1004
#5  0x2ab4df88 in __pthread_alt_lock (lock=Cannot
access memory at address 0x2afc8600
) at restart.h:34
#6  0x2ab47f74 in __pthread_mutex_lock (mutex=Cannot
access memory at address 0x2afc8600
) at mutex.c:120
#7  0x2af657dc in Tcl_MutexLock (mutexPtr=Cannot
access memory at address 0x2afc8600
) at ../unix/tclUnixThrd.c:370
#8  0x2af3a2c8 in Tcl_NewLongObj (longValue=Cannot
access memory at address 0x2afc8600
) at ../generic/tclObj.c:1797
#9  0x2af0c588 in TclExecuteByteCode (interp=Cannot
access memory at address 0x2afc8600
) at ../generic/tclExecute.c:2076
#10 0x2aedf22c in Tcl_EvalObjEx (interp=Cannot access
memory at address 0x2afc8600
) at ../generic/tclBasic.c:2733
#11 0x2aef35d4 in Tcl_WhileObjCmd (dummy=Cannot access
memory at address 0x2afc8600
) at ../generic/tclCmdMZ.c:2872
#12 0x2af3b968 in EvalObjv (interp=Cannot access
memory at address 0x2afc8600
) at ../generic/tclParse.c:932
#13 0x2af3c378 in Tcl_EvalEx (interp=Cannot access
memory at address 0x2afc8600
) at ../generic/tclParse.c:1393
#14 0x2af3c74c in Tcl_Eval (interp=Cannot access
memory at address 0x2afc8600
) at ../generic/tclParse.c:1548

Any help or info is greatly appreciated.

-Raj



 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

Re: [Tcl-Threads] thread::transfer and memory leak

[Oleg D. <ol...@vs...>]

>> I am developing project using Tcl + Thread (BitTorrent tracker). At first
I
>> tried to use model where main thread after accepting new connection
(using
>> socket -server) transfers connection socket to free thread using
>> thread::transfer. But testing of this model reveals slow memory leak
(about
>> 1Mb/minute with requests rate about 100 req/sec). Using Tcl memory
debugging
>>
>> (Tcl and Thread built with --enable-symbols=mem) and memory command I
found
>> that memory leaks after each thread::transfer call. This observes on
latest
>> Tcl/Threads versions as well (tcl8.4.14 and thread2.6.5).
>>
>> Is this a known issue ? Is thread::transfer requires some extra dealing
with
>> transferred filedescriptors before or after transfer ?
>
> You are making sure to close the connections made, right?  Do you have any
> more info from your tracing, or perhaps a code snippet (small) to
reproduce?

Sure. This is my PR:

http://sourceforge.net/tracker/index.php?func=detail&aid=1603234&group_id=10894&atid=110894

with some extra info, including code.

> Also, is this unix, Windows or OS X?

Solaris 9 (x86 or SPARC - doesn't matter).

--
Oleg Derevenetz <ol...@vs...> OOD3-RIPE
Phone: +7 4732 531789
Fax:   +7 4732 531415         http://www.vsi.ru
CenterTelecom Voronezh ISP    http://isp.vsi.ru

Re: [Tcl-Threads] thread::transfer and memory leak

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

Oleg Derevenetz wrote:
> I am developing project using Tcl + Thread (BitTorrent tracker). At =
first I=20
> tried to use model where main thread after accepting new connection =
(using=20
> socket -server) transfers connection socket to free thread using=20
> thread::transfer. But testing of this model reveals slow memory leak =
(about=20
> 1Mb/minute with requests rate about 100 req/sec). Using Tcl memory =
debugging

> (Tcl and Thread built with --enable-symbols=3Dmem) and memory command =
I found=20
> that memory leaks after each thread::transfer call. This observes on =
latest=20
> Tcl/Threads versions as well (tcl8.4.14 and thread2.6.5).
>=20
> Is this a known issue ? Is thread::transfer requires some extra =
dealing with

> transferred filedescriptors before or after transfer ?

You are making sure to close the connections made, right?  Do you have =
any
more info from your tracing, or perhaps a code snippet (small) to =
reproduce?

Also, is this unix, Windows or OS X?

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/

[Tcl-Threads] thread::transfer and memory leak

[Oleg D. <ol...@vs...>]

I am developing project using Tcl + Thread (BitTorrent tracker). At first I 
tried to use model where main thread after accepting new connection (using 
socket -server) transfers connection socket to free thread using 
thread::transfer. But testing of this model reveals slow memory leak (about 
1Mb/minute with requests rate about 100 req/sec). Using Tcl memory debugging 
(Tcl and Thread built with --enable-symbols=mem) and memory command I found 
that memory leaks after each thread::transfer call. This observes on latest 
Tcl/Threads versions as well (tcl8.4.14 and thread2.6.5).

Is this a known issue ? Is thread::transfer requires some extra dealing with 
transferred filedescriptors before or after transfer ?

--
Oleg Derevenetz <ol...@vs...> OOD3-RIPE
Phone: +7 4732 531789
Fax:   +7 4732 531415         http://www.vsi.ru
CenterTelecom Voronezh ISP    http://isp.vsi.ru

Re: [Tcl-Threads] Multiple threads can not access the same Tcl interpreter

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

Sandrine Vollat wrote:
> I have read in the TCL man that an important constraint of the Tcl threads 
> implementation is that only the thread that created a Tcl interpreter can use 
> that interpreter. In other words, multiple threads can not access the same 
> Tcl interpreter.
> 
> What is exactely the problem ?
> What can we do to have this working fine ?

As Andrew noted, this is by design, and it is a good design.  You can 
actually access a single interpreter from multiple threads, but then you 
get into the usual caveats of handling inter-thread access.  You will 
need to use mutexes and such to make sure that only a single thread is 
accessing that interp at any one time.

However, you are likely better off using the excellent message passing 
mechanisms that are already provided for you.

Jeff

Re: [Tcl-Threads] Multiple threads can not access the same Tcl interpreter

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

On Tue, Oct 10, 2006 at 04:40:31PM +0200, Sandrine Vollat wrote:

> I have read in the TCL man that an important constraint of the Tcl threads 
> implementation is that only the thread that created a Tcl interpreter can use 
> that interpreter. In other words, multiple threads can not access the same 
> Tcl interpreter.
> 
> What is exactely the problem ?

There is no "problem".  The "apartment model" of the Tcl's
multi-threading support and of the Tcl Threads extension is by design,
and it's a good one, works very well.

> What can we do to have this working fine ?

It is working fine, and has been for many years.

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

[Tcl-Threads] Multiple threads can not access the same Tcl interpreter

[Sandrine V. <san...@ce...>]

Hi,

I have read in the TCL man that an important constraint of the Tcl threads 
implementation is that only the thread that created a Tcl interpreter can use 
that interpreter. In other words, multiple threads can not access the same 
Tcl interpreter.

What is exactely the problem ?
What can we do to have this working fine ?

Thanks by advance for your answer.

Best regards,
Sandrine Vollat.

[Tcl-Threads] Call For Papers: 13th Annual Tcl/Tk Conference, Oct. 9-13, 2006

[<aku...@sh...>]

Tcl/Tk
 - radically simple
 - radically flexible
 - radically powerful

Announcing the 13th Annual Tcl/Tk Conference

October 9-13, 2006
Naperville, Illinois USA

Learn from the experts, share your experience - the annual Tcl/Tk
conference is your opportunity to engage with the Tcl/Tk core team and
your fellow peers.

The conference program will include:
  * Presentations and tutorials
  * The (Active)State of Tcl talk by Tcl/Tk release manager Jeff Hobbs
  * Birds of a Feather (BOF) sessions
  * Invited key-note talks
  * Discussion forums with the Tcl/Tk core team

Call For Papers

You are invited and indeed encouraged to submit proposals for
presentations and tutorials. The conference schedule will consist of two
days of tutorials (Monday - Tuesday) and 3 days for the main
conference (Wednesday - Friday).

The conference provides you an opportunity to report on original
research and applications of Tcl/Tk and related technology. The
audience will consist of practitioners and researchers who are
intermediate or experienced users of Tcl/Tk.  For this reason, reports
on experiences and applications should draw out lessons for other
Tcl/Tk developers.

Topics will include, but are not limited to:

  * Application of Tcl/Tk in industries as diverse as engineering,
      industrial controls, broadcasting, financial services,
      medical and electronic design
  * Networking with Tcl/Tk, including distributed applications and network
      management
  * New widgets and techniques for GUI design with Tk
  * Simulation and application steering with Tcl/Tk
  * Tcl/Tk on handheld and embedded devices
  * New Tcl extensions and add-ons, including Tcllib and Tklib
  * Tcl/Tk centric operating environments

Submission Guidelines

If you are interested in submitting a paper you should send an
abstract of about 100 words and a summary of maximum two pages. Omit
extraneous or redundant information. Length is not a direct factor in
judging the quality of the submission.

If submitting a tutorial proposal you should send an outline of the
tutorial and a brief biography, and clearly indicate whether the
tutorial is of half-day or full-day duration.

Send submissions as plain text to <tc...@tc...> no later than May
31, 2006.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

The program committee will review and evaluate papers according to
the following criteria:
  * Quantity and quality of novel content
  * Relevance and interest to the Tcl/Tk community
  * Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application.  Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread.  All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

Registration Information

More information on the conference will be available in Spring 2006 at
the conference web site (http://www.tcl.tk/community/tcl2006/) and
published on various Tcl/Tk related information channels.

To keep in touch with conference announcements and Tcl events in
general, subscribe to the tcl-announce list at:

   http://listserv.activestate.com/mailman/mysubs?show=announce

by entering your email and selecting Tcl-announce.

Conference Committee

Cyndy Lilagan     Eolas Technologies              Facilities Coordination
Clif Flynt        Noumena Corp                    General Chair
Steve Redler IV   SR Technology                   Program Chair
Steve Landers     Digital Smarties                Program Co-chair
Kevin Kenny       GE Global Research Center
Jeffrey Hobbs     ActiveState
Andreas Kupries   ActiveState
Mike Doyle        Eolas Technologies
Ron Fox           NSCL Michigan State University
Donal Fellows     University of Manchester
Gerald Lester     HMS Software
Larry Virden      Tcl FAQ Maintainer

Contact Information

tc...@tc...
http://www.tcl.tk/community/tcl2006/


--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

RE: [Tcl-Threads] does tpool::post really work in blocking mode?

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

What platform and version was that using?  Using ActiveTcl 8.4.11.2
and 8.5.0.0b4 on Windows XP, I got:

C:\temp>tclsh84 foo.tcl
1
tid00000C3C tid00000BEC
2
tid00000C3C tid00000BEC

C:\temp>tclsh85 foo.tcl
1
tid00000CAC tid000008E0
2
tid00000CAC tid000008E0

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos 

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Roster Wang
Sent: November 6, 2005 7:17 PM
To: tcl...@li...
Subject: [Tcl-Threads] does tpool::post really work in blocking mode?


package require Thread
set script {
    thread::send %s [list set flag 1]
}
set script [format $script [thread::id]]
set pid [tpool::create -maxworkers 1]
set flag 0
while { !$flag } {
    puts [tpool::post $pid $script]
    puts [thread::names]
}
tpool::release $pid

since only one worker is allowed in this case, there will be only two jobs
generated by tpool.
at the every beginning, the worker picks the first job and expect to set the
flag in main thread. 
Meanwhile, the main thread waits in event loop until the woker set the flag
successfully and takes the second job from the pool.
Then the main thread won't post anymore job because flag is set.

However, I got confused by receiving the following result:
1
tid00000548
2
tid00000548
3
tid00000548
4
tid00000548
5
tid00000548
6
tid00000510 tid00000548
7
tid00000510 tid00000548
can anyone explain this? thanks a lot

[Tcl-Threads] does tpool::post really work in blocking mode?

[Roster W. <kx...@gm...>]

package require Thread
set script {
thread::send %s [list set flag 1]
}
set script [format $script [thread::id]]
set pid [tpool::create -maxworkers 1]
set flag 0
while { !$flag } {
puts [tpool::post $pid $script]
puts [thread::names]
}
tpool::release $pid

since only one worker is allowed in this case, there will be only two jobs
generated by tpool.
at the every beginning, the worker picks the first job and expect to set th=
e
flag in main thread.
Meanwhile, the main thread waits in event loop until the woker set the flag
successfully and takes the second job from the pool.
Then the main thread won't post anymore job because flag is set.

However, I got confused by receiving the following result:
1
tid00000548
2
tid00000548
3
tid00000548
4
tid00000548
5
tid00000548
6
tid00000510 tid00000548
7
tid00000510 tid00000548
can anyone explain this? thanks a lot

[Tcl-Threads] boost::threads and tcl/tk

[<lu...@gm...>]

Hi,

I'm using boost::threads in my project and want to use tcl/tk as interpreter
and gui.

Via boost::threads i've created two main threads :

- one running the tcl interpreter (and the gui incl. DoOneEvent loop)
  (The Tcl Interpreter and the Tk Eventloop has been encapsulated in an
  own object.)

- one running my projects computations.

Basically i want to access tk widgets from my computations to show results
and update gauges etc.. Since both, my computation thread and the tcl
interpreter/gui thread can access the same ressource (widget, vars) it could
come to problems.

Now i have a question:

- does it make sense to use a boost::mutex on every Tcl_Eval-Invocation and
in the DoOneEvent loop since Tcl/Tk uses pthreads itself and runs an own
thread management ? 
- or more generally WHERE do i use my mutex to make the app stable ?

Yours Sincerly
-Lukas

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

[Tcl-Threads] Tcl/Tk 2005 Conference - Schedules available now, Registration is open

[<aku...@sh...>]

Tcl/Tk 2005 Conference Schedule & Registration
==============================================

The 12th Tcl/Tk Conference Schedules are available.

The tutorials and paper presentation schedules have been 
finalized and are available at:

http://www.tcl.tk/community/tcl2005/tut2005.html
http://www.tcl.tk/community/tcl2005/schedule.html

The abstracts for the selected papers are available at:

http://www.tcl.tk/community/tcl2005/abstracts.html

The conference dinner will be on Wednesday evening.  
Blueteam will be providing a social hour with drinks
and munchies on Thursday evening.

Registration is open for tutorials and technical 
sessions at:

http://www.tcl.tk/community/tcl2005/reg.html


Program Committee:
==================
 Donal  Fellows       University of Manchester
 Clif   Flynt         Noumena Corp.
 Ron    Fox           NSCL Michigan State University
 Jeff   Hobbs         ActiveState Corp.
 Steve  Landers       Digital Smarties
 Gerald Lester        HMS Software
 Cyndy  Lilagan       Eolas Technologies Inc.
 Arjen  Markus        WL | Delft Hydraulics

--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------