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
> 
> 
>