From: Frank Uray on
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
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
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
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
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
> .
>
 |  Next  |  Last
Pages: 1 2
Prev: Image size mystery
Next: Web Setup Project failure