Cancel Background worker in multi tier environment

[parez]

I start a BackGroundWorke r to populate a grid. It is started off in
the ui layer

The thread follows( cannot think of a better word) the path

UI->Layer1->Layer2->Communicatio n Layer

and it blocks (the server is executing somthing where which takes
time)

How do i cancel this background worker?
Is there anyway i can access the thread object used by the
backgroundworke r and then stop it?
if i can is there anything wroong with it?

TIA

[parez]

On Jun 3, 7:24 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Tue, 03 Jun 2008 15:13:55 -0700, parez <psaw...@gmail. comwrote:

The
only advantage I would get by using async reads is ability to close
the
socket.
Coz there is nothing else i need to do between BeginRead and EndRead
(other than may be checking the flag)

I don't see how the async/sync API affects this. Even if you used the
sync API, but called it from a thread, you could close the Stream (or
Socket...whatev er it is you're actually using) and an exception would be
thrown, terminating the operation.

1)
If I use sync api, I would be blocking on the read hence not able to
close the socket.

That's not true. You can't close the socket from the thread that's
blocking, but that's trivially obvious and not relevant. You can close
the socket from whatever thread needs to interrupt the thread that's
blocking. A blocking read can be interrupted just as easily as a
non-blocking read.

Pete

So how can i cancel the blocked read? Should i raise and handle a
RequestCancelle d Event?

[Peter Duniho]

On Wed, 04 Jun 2008 06:24:43 -0700, parez <ps*****@gmail. comwrote:

1)
If I use sync api, I would be blocking on the read hence not able to
close the socket.

That's not true. You can't close the socket from the thread that's
blocking, but that's trivially obvious and not relevant. You can close
the socket from whatever thread needs to interrupt the thread that's
blocking. A blocking read can be interrupted just as easily as a
non-blocking read.

So how can i cancel the blocked read?

Same as you cancel a non-blocking read: close the i/o object.

Should i raise and handle a RequestCancelle d Event?

Should you raise and handle what RequestCancelle d event?

Pete

[parez]

On Jun 4, 2:10 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Wed, 04 Jun 2008 06:24:43 -0700, parez <psaw...@gmail. comwrote:

1)
If I use sync api, I would be blocking on the read hence not able to
close the socket.

That's not true. You can't close the socket from the thread that's
blocking, but that's trivially obvious and not relevant. You can close
the socket from whatever thread needs to interrupt the thread that's
blocking. A blocking read can be interrupted just as easily as a
non-blocking read.

So how can i cancel the blocked read?

Same as you cancel a non-blocking read: close the i/o object.

Should i raise and handle a RequestCancelle d Event?

Should you raise and handle what RequestCancelle d event?

Pete

what i am trying to ask is which thread will/should close the i/o
object? since the current thread is blocked on the read, i thougtt i
could create a RequestCancled event which would be raised by the UI
and it could be handled by the communciation Layer or any other
layer..

[Peter Duniho]

On Wed, 04 Jun 2008 11:43:49 -0700, parez <ps*****@gmail. comwrote:

what i am trying to ask is which thread will/should close the i/o
object? since the current thread is blocked on the read, i thougtt i
could create a RequestCancled event which would be raised by the UI
and it could be handled by the communciation Layer or any other
layer..

You could do that. But I don't see the point. It would mean that the
communication layer would wind up not just a service that your GUI uses,
but also as an active user/subscriber of the API that your GUI exposes.

Why not just have a method in your communication layer that the GUI can
call to cancel the i/o? Which thread it's called from doesn't really
matter; it just depends on what circumstance causes you to want to cancel
the i/o. If it's a user pushing a "Cancel" button, it'll probably be the
GUI thread that calls the method. If it's a timer or response to some
other condition, it could be some other thread (as appropriate to the
timer or other condition).

Pete

[parez]

On Jun 4, 2:51 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Wed, 04 Jun 2008 11:43:49 -0700, parez <psaw...@gmail. comwrote:

what i am trying to ask is which thread will/should close the i/o
object? since the current thread is blocked on the read, i thougtt i
could create a RequestCancled event which would be raised by the UI
and it could be handled by the communciation Layer or any other
layer..

You could do that. But I don't see the point. It would mean that the
communication layer would wind up not just a service that your GUI uses,
but also as an active user/subscriber of the API that your GUI exposes.

Why not just have a method in your communication layer that the GUI can
call to cancel the i/o? Which thread it's called from doesn't really
matter; it just depends on what circumstance causes you to want to cancel
the i/o. If it's a user pushing a "Cancel" button, it'll probably be the
GUI thread that calls the method. If it's a timer or response to some
other condition, it could be some other thread (as appropriate to the
timer or other condition).

Pete

Hmm.. This means I will have to create another path down the tiers
for request cancellations and also keep a reference of the objects of
the underylying tier so i can traverse down to the blocked object.

Thanks Pete and rest for the replies.

[Peter Duniho]

On Thu, 05 Jun 2008 09:11:07 -0700, parez <ps*****@gmail. comwrote:

Hmm.. This means I will have to create another path down the tiers
for request cancellations and also keep a reference of the objects of
the underylying tier so i can traverse down to the blocked object.

Yes. But I don't see how that wouldn't be the case regardless of the i/o
implementation. You can't cancel something unless you know what that
something is. :)

Pete

[parez]

On Jun 5, 2:33 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Thu, 05 Jun 2008 09:11:07 -0700, parez <psaw...@gmail. comwrote:

Hmm.. This means I will have to create another path down the tiers
for request cancellations and also keep a reference of the objects of
the underylying tier so i can traverse down to the blocked object.

Yes. But I don't see how that wouldn't be the case regardless of the i/o
implementation. You can't cancel something unless you know what that
something is. :)

Pete

Yea.. When i designed it, I didn't consider the cancellation
possibillity or a need to follow an existing object trail.Its small
change though.

Thanks for your input.