TCL thread problem

[py]

Hi,

I had been using thread structure like this on my tcl8.4, win2k8 R2 64b
platform

set var 3
set tid [thread::create {
#1
#initialization code for aux thread
proc pro1 def {} {
#blah
}
thread::wait
}]

#2
set waiting 1
after 10000 {set waiting 0}
vwait waiting

#other stuff here

#3
thread::send -async $tid [list proc1]

Once every so often (let say 2/100 execution cycle), when the code gets
to #3, tcl pops up an error that says "proc1" is undefined.

Now, as I understand, this is happening because there is no guaranteed
that #1 is executed before #3. thread::create returns as soon as the
thread is created, without executing all the aux thread initialization
code. So #2 is bought in as a stop gap. It gives some breathing room for
the thread finish initialization and move to event loop. I don't really
like this workaround, since it doesn't scale with the evolving
initialization code. So if the wait time is not large enough, I would
still see the proc not define error. What other option do I have?

Also, is there any way to pass a parameter from the main thread to the
spawn thread (the var variable) during thread::create?

Thanks

[Ralf Fassel]

* py <pyj...@shaw.ca>

| set tid [thread::create {
| #1
| #initialization code for aux thread
| proc pro1 def {} {
| #blah
| }
| thread::wait
| }]

--<snip-snip>--

| Once every so often (let say 2/100 execution cycle), when the code
| gets to #3, tcl pops up an error that says "proc1" is undefined.
>
| Now, as I understand, this is happening because there is no guaranteed
| that #1 is executed before #3. thread::create returns as soon as the
| thread is created, without executing all the aux thread initialization
| code.

As I understand tcl::threads, the thread::send from #3 will only get
handled by #1 when the event loop is entered in #1. This is done by
thread::wait only after the proc has been defined, so there is no way
that #1 reacts to the thread::send before the proc has been defined.
Note that there is an obvious typo in the proc name ('pro1' vs 'proc1')
in the code you've posted which might be the cause of the problem.

R'

[Alexandre Ferrieux]

That's strange. This race condition should happen only if your
"initialization code for aux thread"calls the event loop (with
[update], [vwait], [thread::wait], sync [http::geturl] or similar
package doing it under the scenes). Please clarify, or better try to
reduce the code and see if you still get the bug.

>
> Also, is there any way to pass a parameter from the main thread to the
> spawn thread (the var variable) during thread::create?
>

Thread::create's argu;ent is a string, you can manipulate it.
Typically:

set initcode {
# blah
proc ...
proc ...
set params }

append initcode [list $params] \n

-Alex

[py]

Thanks guys. You are right, there are "update" in my initialization code
that make the thread enter event loop prematurely. I was aware of vwait
and thread::wait, didn't know about "update". After I made the change,
the race condition is gone