Prev: Image size mystery
Next: Web Setup Project failure
From: Frank Uray on 4 Jun 2010 08:05 Hi all I have some trouble with threading: I have a control thread which it is starting another thread. This thread is executing some long run SQL statements. The control thread is looping and checking for a cancel flag which the user can set to cancel all. In the control thread, I tried to abort the other thread, but no reaction ... Can somebody tell me how to kill a thread which is busy ? Thanks and best regards Frank Uray
From: Peter Duniho on 4 Jun 2010 11:19 Frank Uray wrote: > Hi all > > I have some trouble with threading: > I have a control thread which it is starting another > thread. This thread is executing some long run SQL statements. > The control thread is looping and checking for a cancel flag > which the user can set to cancel all. > > In the control thread, I tried to abort the other thread, > but no reaction ... > Can somebody tell me how to kill a thread which is busy ? The best way, and the only reliable way, is to provide a signal to the worker thread so _it_ knows to interrupt its own work and exit. Ironically, your description makes it sound like you are in fact providing this signal, but to the wrong thread. You're not clear on what else the "control thread" is doing, but if all it's doing is looping inspecting a flag over and over, then that's not a good design. Without seeing a concise-but-complete code example that reliably demonstrates the issue, it's hard to say specifically what should change. But if in fact the control thread is doing nothing but looking at that flag, it would probably make more sense to just have the control thread be the worker thread and don't create the second thread. In either case, whichever thread is doing the SQL work, it should be looking for a flag that is set when you want it to exit. Note that the flag needs to be synchronized in some fashion (for a flag, often just making it "volatile" is sufficient), and it needs to be inspected regularly by the thread that should exit when the flag is set. If a particular call to a SQL operation takes a long time, the thread will not be able to exit until that operation is done. Your design should tolerate that sort of delay (perhaps by just letting the thread continue to run but ignoring any result after it's been canceled). Pete
From: Bjørn Brox on 4 Jun 2010 11:51 Frank Uray skrev: > Hi all > > I have some trouble with threading: > I have a control thread which it is starting another > thread. This thread is executing some long run SQL statements. > The control thread is looping and checking for a cancel flag > which the user can set to cancel all. > > In the control thread, I tried to abort the other thread, > but no reaction ... > Can somebody tell me how to kill a thread which is busy ? > > Thanks and best regards > Frank Uray > Killing hard and brutally a thread which are executing "long run SQL statements" does not sound like a good idea, unless it it just queries. The SQL thread should it selves check -- Bjørn Brox
From: Frank Uray on 4 Jun 2010 15:07 Hi Peter Thanks for your answer. Well, I know it is better to give the thread a signal to cancel, but when it is busy like when running SQL Statement, there is now way ... Thanks anyway, Frank "Peter Duniho" wrote: > Frank Uray wrote: > > Hi all > > > > I have some trouble with threading: > > I have a control thread which it is starting another > > thread. This thread is executing some long run SQL statements. > > The control thread is looping and checking for a cancel flag > > which the user can set to cancel all. > > > > In the control thread, I tried to abort the other thread, > > but no reaction ... > > Can somebody tell me how to kill a thread which is busy ? > > The best way, and the only reliable way, is to provide a signal to the > worker thread so _it_ knows to interrupt its own work and exit. > > Ironically, your description makes it sound like you are in fact > providing this signal, but to the wrong thread. You're not clear on > what else the "control thread" is doing, but if all it's doing is > looping inspecting a flag over and over, then that's not a good design. > > Without seeing a concise-but-complete code example that reliably > demonstrates the issue, it's hard to say specifically what should > change. But if in fact the control thread is doing nothing but looking > at that flag, it would probably make more sense to just have the control > thread be the worker thread and don't create the second thread. > > In either case, whichever thread is doing the SQL work, it should be > looking for a flag that is set when you want it to exit. Note that the > flag needs to be synchronized in some fashion (for a flag, often just > making it "volatile" is sufficient), and it needs to be inspected > regularly by the thread that should exit when the flag is set. If a > particular call to a SQL operation takes a long time, the thread will > not be able to exit until that operation is done. Your design should > tolerate that sort of delay (perhaps by just letting the thread continue > to run but ignoring any result after it's been canceled). > > Pete > . >
From: Frank Uray on 4 Jun 2010 15:33
Hi Bjørn Well, sometimes it is necessary to do that, like in SQL Management Studio. Regards Frank Uray "Bjørn Brox" wrote: > Frank Uray skrev: > > Hi all > > > > I have some trouble with threading: > > I have a control thread which it is starting another > > thread. This thread is executing some long run SQL statements. > > The control thread is looping and checking for a cancel flag > > which the user can set to cancel all. > > > > In the control thread, I tried to abort the other thread, > > but no reaction ... > > Can somebody tell me how to kill a thread which is busy ? > > > > Thanks and best regards > > Frank Uray > > > Killing hard and brutally a thread which are executing "long run SQL > statements" does not sound like a good idea, unless it it just queries. > > The SQL thread should it selves check > > -- > Bjørn Brox > . > |