From: Duquette, W. H (318K) <wil...@jp...> - 2011-11-01 21:37:30
|
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 -- Will Duquette -- Wil...@jp... Athena Development Lead -- Jet Propulsion Laboratory "It's amazing what you can do with the right tools." |
From: Rusty B. <me...@ru...> - 2011-11-02 00:56:05
|
I don't believe it's true that you can only have Tk in one thread. It's been a while but I'm about 90% sure that I have some applications that use Tk in every thread. You will get a toplevel window for each thread you use it in, though. thread::wait or vwait will work to stay in the event loop, there are probably other techniques also. But the basic idea is, you have to give it somewhere to wait, otherwise it's going to fall through and exit. The same is true for many event-loop based programming languages. 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 > -- > Will Duquette -- Wil...@jp... > Athena Development Lead -- Jet Propulsion Laboratory > "It's amazing what you can do with the right tools." > > > > ------------------------------------------------------------------------------ > RSA® Conference 2012 > Save $700 by Nov 18 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev1 > > > _______________________________________________ > Tcl-Threads mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-threads |
From: Rusty B. <me...@ru...> - 2011-11-02 01:44:02
|
package require Thread set i1 [thread::create] set i2 [thread::create] pack [button .b -text {main thread} -command {tk_messageBox -message "This is from main thread"}] set command { package require Tk pack [button .b -text $::text -command {tk_messageBox -message "This is from $::text"}] } thread::send $i1 "set ::text {thread1}" thread::send $i1 $command thread::send $i2 "set ::text {thread2}" thread::send $i2 $command |
From: Duquette, W. H (318K) <wil...@jp...> - 2011-11-02 14:50:54
|
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 -- Will Duquette -- Wil...@jp... 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...@ru...<mailto:me...@ru...>> 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 -- Will Duquette -- Wil...@jp...<mailto:Wil...@jp...> Athena Development Lead -- Jet Propulsion Laboratory "It's amazing what you can do with the right tools." ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Tcl-Threads mailing list Tcl...@li...<mailto:Tcl...@li...>https://lists.sourceforge.net/lists/listinfo/tcl-threads |
From: Rusty B. <me...@ru...> - 2011-11-02 14:58:35
|
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 > > -- > Will Duquette -- Wil...@jp... > 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...@ru...> 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 >>> -- >>> Will Duquette -- Wil...@jp... >>> Athena Development Lead -- Jet Propulsion Laboratory >>> "It's amazing what you can do with the right tools." >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> RSA® Conference 2012 >>> Save $700 by Nov 18 >>> Register now! >>> http://p.sf.net/sfu/rsa-sfdev2dev1 >>> >>> >>> _______________________________________________ >>> Tcl-Threads mailing list >>> Tcl...@li...https://lists.sourceforge.net/lists/listinfo/tcl-threads >> |
From: Duquette, W. H (318K) <wil...@jp...> - 2011-11-02 15:10:33
|
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 -- Wil...@jp... 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...@ru...<mailto:me...@ru...>> 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 -- Will Duquette -- Wil...@jp...<mailto:Wil...@jp...> 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...@ru...<mailto:me...@ru...>> 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 -- Will Duquette -- Wil...@jp...<mailto:Wil...@jp...> Athena Development Lead -- Jet Propulsion Laboratory "It's amazing what you can do with the right tools." ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Tcl-Threads mailing list Tcl...@li...<mailto:Tcl...@li...>https://lists.sourceforge.net/lists/listinfo/tcl-threads |
From: Jeff H. <je...@ac...> - 2011-11-02 16:43:33
Attachments:
getimages.tcl
|
Actually a basekit/tclkit will usually be built with Tk statically included, but not as a "wish" - you still have to 'package require Tk' to get it. The key thing missing in Will's request is the platform. Note that even Welch's last edition (for 8.5, that I assisted with) was finished many years ago. One of the issues was that X11 itself use to not be thread-safe. This isn't the case anymore (at least on systems most people would be using ...). Tk may need a final clean for static vars, but it will work fine if you isolate it to one thread. To be safe, just use Tk in the main thread, and relegate other threads to help. I'm attaching an app that is an example of this, fetching image data in multiple threads and returning it to the main Tk thread. I do recall seeing the subthread issue before ... can't recall the specifics, but really just arrange it to have Tk in the main thread. If you are doing this from scratch, that shouldn't add any extra work. This may not always work with other extensions, but most widget extensions should be fine. Jeff On 02/11/2011 7:59 AM, Rusty Brooks 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 >> >> >> On 11/1/11 6:43 PM, "Rusty Brooks" <me...@ru... >> <mailto:me...@ru...>> 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 |