Thread question regarding vwait
in [TCL]
|
Prev: Subtyping vs Inheritance [Was: Re: Google's Go language and "goroutines"]
Next: Subtyping vs Inheritance [Was: Re: Google's Go language and "goroutines"]
From: Helmut Giese on 22 Nov 2009 16:11 Hello out there, contemplating the design for an upcoming application I implemented a very basic prototype using Tcl's thread package. BTW, it's truly amazing how fast you can get a multi-threading program to work using this package - the errors I had were all due to my insufficient reading of the documentation. Scenario: I have a worker thread which must be prepared to stop and continue execution. I found it easy to implement this via the 'tsv' functions, e.g. in order to check if the thread should stop I use in the central 'while' loop # check: stop? if {[tsv::set ip stop]} { break } where 'ip stop' is set by the "master". Easy. Then, in order to know when to continue I use polling # wait for 'continue' while {[tsv::set ip stop]} { after 50 } Reacting only within 50 ms is ok here, and executing a couple of commands every 50 ms doesn't burn many CPU cycles - but it's a bit unpleasing esthetically. It would be perfect if I could use a 'vwait' instead - but I don't know how. Can someone help me with my Sunday evening esthetic woes? Best regards Helmut Giese
From: Robert Heller on 22 Nov 2009 17:23 At Sun, 22 Nov 2009 22:11:01 +0100 Helmut Giese <hgiese(a)ratiosoft.com> wrote: > > Hello out there, > contemplating the design for an upcoming application I implemented a > very basic prototype using Tcl's thread package. > BTW, it's truly amazing how fast you can get a multi-threading program > to work using this package - the errors I had were all due to my > insufficient reading of the documentation. > > Scenario: I have a worker thread which must be prepared to stop and > continue execution. > > I found it easy to implement this via the 'tsv' functions, e.g. in > order to check if the thread should stop I use in the central 'while' > loop > # check: stop? > if {[tsv::set ip stop]} { > break > } > where 'ip stop' is set by the "master". Easy. > > Then, in order to know when to continue I use polling > # wait for 'continue' > while {[tsv::set ip stop]} { > after 50 > } > Reacting only within 50 ms is ok here, and executing a couple of > commands every 50 ms doesn't burn many CPU cycles - but it's a bit > unpleasing esthetically. > > It would be perfect if I could use a 'vwait' instead - but I don't > know how. vwait is part of the event loop logic. It is *bad* to mix threading and event loops. Specifically, you can have the event loop in only ONE thread. > > Can someone help me with my Sunday evening esthetic woes? > Best regards > Helmut Giese > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: Gerald W. Lester on 22 Nov 2009 22:55 Robert Heller wrote: > At Sun, 22 Nov 2009 22:11:01 +0100 Helmut Giese <hgiese(a)ratiosoft.com> wrote: > >> Hello out there, >> contemplating the design for an upcoming application I implemented a >> very basic prototype using Tcl's thread package. >> BTW, it's truly amazing how fast you can get a multi-threading program >> to work using this package - the errors I had were all due to my >> insufficient reading of the documentation. >> >> Scenario: I have a worker thread which must be prepared to stop and >> continue execution. >> >> I found it easy to implement this via the 'tsv' functions, e.g. in >> order to check if the thread should stop I use in the central 'while' >> loop >> # check: stop? >> if {[tsv::set ip stop]} { >> break >> } >> where 'ip stop' is set by the "master". Easy. >> >> Then, in order to know when to continue I use polling >> # wait for 'continue' >> while {[tsv::set ip stop]} { >> after 50 >> } >> Reacting only within 50 ms is ok here, and executing a couple of >> commands every 50 ms doesn't burn many CPU cycles - but it's a bit >> unpleasing esthetically. >> >> It would be perfect if I could use a 'vwait' instead - but I don't >> know how. > > vwait is part of the event loop logic. It is *bad* to mix threading and > event loops. Specifically, you can have the event loop in only ONE thread. Robert, Can you point me to something that says that? Now you should not be doing vwaits on shared variables. The reason I ask is because threads in Tcl normally communicate via sending and receiving messages (::thread::wait) -- normally waiting in the event loop for a message to arrive. Now a while back, on some Linuxes, there was a restriction that the X event loop be used only from a single thread (this was because some of the Xlibs were not thread safe). -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+
From: Will Duquette on 22 Nov 2009 23:54 On Nov 22, 7:55 pm, "Gerald W. Lester" <Gerald.Les...(a)cox.net> wrote: > Robert Heller wrote: > > At Sun, 22 Nov 2009 22:11:01 +0100 Helmut Giese <hgi...(a)ratiosoft.com> wrote: > > >> Hello out there, > >> contemplating the design for an upcoming application I implemented a > >> very basic prototype using Tcl's thread package. > >> BTW, it's truly amazing how fast you can get a multi-threading program > >> to work using this package - the errors I had were all due to my > >> insufficient reading of the documentation. > > >> Scenario: I have a worker thread which must be prepared to stop and > >> continue execution. > > >> I found it easy to implement this via the 'tsv' functions, e.g. in > >> order to check if the thread should stop I use in the central 'while' > >> loop > >> # check: stop? > >> if {[tsv::set ip stop]} { > >> break > >> } > >> where 'ip stop' is set by the "master". Easy. > > >> Then, in order to know when to continue I use polling > >> # wait for 'continue' > >> while {[tsv::set ip stop]} { > >> after 50 > >> } > >> Reacting only within 50 ms is ok here, and executing a couple of > >> commands every 50 ms doesn't burn many CPU cycles - but it's a bit > >> unpleasing esthetically. > > >> It would be perfect if I could use a 'vwait' instead - but I don't > >> know how. > > > vwait is part of the event loop logic. It is *bad* to mix threading and > > event loops. Specifically, you can have the event loop in only ONE thread. > > Robert, > > Can you point me to something that says that? > > Now you should not be doing vwaits on shared variables. > > The reason I ask is because threads in Tcl normally communicate via sending > and receiving messages (::thread::wait) -- normally waiting in the event > loop for a message to arrive. > > Now a while back, on some Linuxes, there was a restriction that the X event > loop be used only from a single thread (this was because some of the Xlibs > were not thread safe). Gerald, Is Tk thread-safe? I'd understood that Tcl was thread-safe but that Tk wasn't.
From: Gerald W. Lester on 23 Nov 2009 00:05
Will Duquette wrote: > On Nov 22, 7:55 pm, "Gerald W. Lester" <Gerald.Les...(a)cox.net> wrote: >> Robert Heller wrote: >>> At Sun, 22 Nov 2009 22:11:01 +0100 Helmut Giese <hgi...(a)ratiosoft.com> wrote: >>>> Hello out there, >>>> contemplating the design for an upcoming application I implemented a >>>> very basic prototype using Tcl's thread package. >>>> BTW, it's truly amazing how fast you can get a multi-threading program >>>> to work using this package - the errors I had were all due to my >>>> insufficient reading of the documentation. >>>> Scenario: I have a worker thread which must be prepared to stop and >>>> continue execution. >>>> I found it easy to implement this via the 'tsv' functions, e.g. in >>>> order to check if the thread should stop I use in the central 'while' >>>> loop >>>> # check: stop? >>>> if {[tsv::set ip stop]} { >>>> break >>>> } >>>> where 'ip stop' is set by the "master". Easy. >>>> Then, in order to know when to continue I use polling >>>> # wait for 'continue' >>>> while {[tsv::set ip stop]} { >>>> after 50 >>>> } >>>> Reacting only within 50 ms is ok here, and executing a couple of >>>> commands every 50 ms doesn't burn many CPU cycles - but it's a bit >>>> unpleasing esthetically. >>>> It would be perfect if I could use a 'vwait' instead - but I don't >>>> know how. >>> vwait is part of the event loop logic. It is *bad* to mix threading and >>> event loops. Specifically, you can have the event loop in only ONE thread. >> Robert, >> >> Can you point me to something that says that? >> >> Now you should not be doing vwaits on shared variables. >> >> The reason I ask is because threads in Tcl normally communicate via sending >> and receiving messages (::thread::wait) -- normally waiting in the event >> loop for a message to arrive. >> >> Now a while back, on some Linuxes, there was a restriction that the X event >> loop be used only from a single thread (this was because some of the Xlibs >> were not thread safe). > > Gerald, > > Is Tk thread-safe? I'd understood that Tcl was thread-safe but that > Tk wasn't. I was under the impression that the problem was the Xlibs and not Tk. That is best left to one of the core people. -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+ |