Rusty,

Re: subprocesses vs. threads -- yeah, I know.  I'd much prefer to avoid threads altogether.  Also I'm well aware of how the Tcl thread model works, as I took a class on it some years back.  I haven't used it for anything since then, though, but as a result I'm not looking for the big ideas here, but rather for the little gotchas.

In general, I'd much prefer just to use the event loop than either subprocesses or threads.  I don't like threads; if it weren't for Tcl's relatively sane threading model I wouldn't be considering using them now.  

My main difficulty is that the application I'm working with was designed as a monolithic app, and splitting into pieces, whether using threads or subprocesses, is going to be a pain in the neck.

Thanks for your input.




--
Will Duquette -- William.H.Duquette@jpl.nasa.gov
Athena Development Lead -- Jet Propulsion Laboratory
"It's amazing what you can do with the right tools."


On 11/2/11 7:59 AM, "Rusty Brooks" <me@rustybrooks.com> wrote:

Does the example I sent work if you add package require Tk for the first thread?  I probably am using wish - but you could also, right?

I've written multiple production apps that are multi-threaded and use Tk - I've never had a problem with it.  That's not to say there couldn't be anything, but it has worked well for me.

Also, due to the threading model that tcl uses, there is not that much advantage to using threading in tcl unless you specifically want to use the thread-shared-variables or other thread-specific features.  Threads in tcl are a lot more seperated from each other than is common in threaded programming, so in many cases you're nearly just as well off exec-ing a sub process to run something that would normally be threaded, and communicating with it via stdin/stdout.  This introduces some complications, sure, but it also often improves some things.  It's usually worth at least considering.

Rusty

On Nov 2, 2011, at 9:50 AM, Duquette, William H (318K) wrote:

I suspect that the difference is that your tclkit is functionally a "wish", whereas I'm running in "tclsh" and doing "package require Tk".

As for using Tk in multiple threads--all of the documentation I've seen on the Threads package that mentions Tk (as, for example, _Practical Programming in Tcl and Tk_) says not to do it.  It's not that it will fail immediately, but that it (under circumstances usually difficult to reproduce or debug) it will fail mysteriously.

Will

--
Athena Development Lead -- Jet Propulsion Laboratory
"It's amazing what you can do with the right tools."


On 11/1/11 6:43 PM, "Rusty Brooks" <me@rustybrooks.com> wrote:

I just tried and it works perfectly fine btw.  Also, I didn't have to do any kind of thread::wait or anything like that, seems to work OK as is with the setup I have (which is using a tclkit with the thread libraries built in)

See attached script

On 11/1/2011 4:36 PM, Duquette, William H (318K) wrote:
Howdy!

Two questions:

1. I know that I can only use Tk in a single thread of a multi-threaded app.  Does it matter which thread it is, i.e., if Tk is NOT running in the main thread is it OK to invoke it in a thread created using thread::create?

(I've tried it; it appears to work; I just need to know whether it will cause me problems in the long run.)

2.  When I invoke Tk using [package require Tk] in a thread created using thread::create, it appears that I have to call [vwait] or [thread::wait] explicitly at the end of the thread startup script, or I don't enter the event loop.  Is this expected behavior?

Thanks very much!

Will
--
Athena Development Lead -- Jet Propulsion Laboratory
"It's amazing what you can do with the right tools."



------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1


_______________________________________________
Tcl-Threads mailing list
Tcl-Threads@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/tcl-threads