How does global HciConnName work. Question about tcl interpr

[Todd Horst]

How does the following code work:

Code:

global HciConnName

It was my understanding that threads in the same process (assuming scripts are placed at the same location ie inbound tps stack) use the same tcl interpreter.

I ran into an error the other day where 2 separate threads using 2 separate scripts (both had the scripts placed on a route) where using a global that was named the same. This wasnt intended so the values were populated by the script A so script B failed because the value wasnt correct. My correction was to make sure the global name was unique. I guess one other caveat is that I was not actually using global i am using upvar, but my understand was that upvar #0 was the same as global.

So if its indeed true that the global space is shared by threads, then how can global HciConnName work?

Topic

[Charlie Bursell]

Unless you are using multi-thread with separate interpreters any scripts in the same thread share the same interpreter and thus the same global space.

By default in a given process there are three places for interpreters, Inbound Protocol thread, Xlate Thread and Outbound Protocol thread.

Your procs were in the route which is owned by the Xlate thread.

If you need safety for your variables might I suggest you consider namespaces?

[Todd Horst]

So i mocked up a little image as to how i see the interpreters working. Please confirm if it is correct.

http://img16.imageshack.us/img16/3376/tclinterpreters.png" />

[Benny Chirackal]

Charlie,

Correct me if I am wrong, each thread in a process has its own tcl interpreter. Since a process can have many protocol threads, each of them has its own interpreter. So it does not depend on the upoc entry (the place where you put the script) unless the upoc is on the xlate thread.

Now does each protocol thread icon in netconfig has its own thread in the process? Or is it possible for them to share a thread in the process as is the case with the xlate thread?

[Eric Fortenberry]

I encountered a similar issue several months ago.

You should be able to use the ‘ps’ command to “see” each thread/interpreter.  I know you can do this on Redhat, but I’m not sure if it’ll work on other environments.

Find your process id for a given Cloverleaf process.  Then run ‘ps -fL $PID’.  What you should see is a list of OS threads (or light-weight processes) tied to that process id.  I found that you get an XLATE thread, a command thread,  and a thread for each Cloverleaf protocol thread that is running.

Since there is only one XLATE thread, I found that any TCL placed in a route shared an interpreter with all other routes in that same process.  The TCL that I placed in either the inbound or outbound tab of each thread appeared to be isolated to their own TCL interpreter.

[Charlie Bursell]

I thought that is what I said.   But it is not each thread that has an interpreter, it is the protocol thread.  Remember that a thread can be both inbound and outbound.  There is an interpreter for IB thread, OB thread and Xlate thread.

I cannot verify the drawing.  It makes no sense to me  😕

[Todd Horst]

its simply saying that a process has on interpreter that is shared on the xlates (routes tab)

then it has 1 interpreter for each thread on the inbound stack, and 1 interpreter for the outbound stack

So if you have 10 threads in a process it would have 21 interpreters or instances of tcl (and therefore the global space)

-10 for each threads inbound tab

-10 for each threads outbound tab

-1 for the routes tab

[Charlie Bursell]

If it is what I and other are saying then I agree

[Todd Horst]

You’re not really being helpful.

Is that indeed the way the engine works?

[Author]

Replies