Async Question

[Amy L.]

I am working on a project where I will have a ton of async DNS calls in a
console application. I would like to process the results of the Aync calls
on the same thread that made the async call. Now I was looking at the Async
WaitHandle options. They are "WaitOne", "WaitAny", and "WaitAll".

I would like to process all of the results that are returned. However, due
to network performance and other factors not all of the results are going to
come in at the same time. There can be up to a 2 second delay between the
start and finish of one of the async queries. However, some may return
immediately.

Of those Async options for the waithandle it does not appear that what I
want to do is possible. Did I miss something when reading the doc's on
this?

Thanks
Amy.

 

[Guest]

Have a look at the callback part of the delegate begininvoke,
then also have a look at the Control.Inovke for getting back onto your
Control thread

 

[Amy L.]

Brian,

That makes sense to me with a WinForms application. However, in a console
application is this still applicable and a valid approach?

Amy

 

[Willy Denoyette [MVP]]

Make synchronous calls on pooled worker threads if this is what you wan't.

Willy.

 

[Amy L.]

Willy,

If I process the calls on worker threads that will not allow me to process
the return on the thread that initiated the worker thread. Are you
suggesting this way because there is no way to implement what I suggest
Asynchronously?

Amy

 

[Willy Denoyette [MVP]]

Willy,

If I process the calls on worker threads that will not allow me to process
the return on the thread that initiated the worker thread. Are you
suggesting this way because there is no way to implement what I suggest
Asynchronously?

Amy

What I meant was, don't use an asynchrononous pattern:
Create a worker thread to invoke a synchronous call and handle the return on
it, that way you handle both - the call and the return - on the same thread,
which was your basic requirement, right?
I don't say it's impossible to implement this using an asynchronous pattern,
if your calling thread is a UI thread, you can use Invoke/BeginInvoke to
marshal the return handler to the UI thread.
However, I don't see why you need to affinitize a return handler to a
specific thread, or am I missing something.

Willy.

 

[clu]

Yours seems quite a strange scenario for using async calls.
Async calls, by definition, do not block the caller (the calling
thread), so their result (return value, out parameters, exceptions ...)
will be received afterwards.
In .NET you can provide a callback which is invoked upon the completion
of a call, but this internally involves threads from the AppDomain
thread pool: when the result is available, one thread is picked up from
the pool (if available) and the callback is invoked into that thread's
context.
So, if you need you calling thread to process itself the results, i
believe you have two choices:
1) Make the call synchronous, which, if I'm not wrong, is not what you
want.
2) Make your calling thread pump on a work item queue. You define a
queue where work items are enqueed as soon as they are available and
implement a sort of message pump on your main thread:

// Main thread:
WorkItem item = null;
while ((item = queue.PickUpItem() as WorkItem) != null) {

// ...

// A work item is available.
item.Process();

// ...
}

In this scenario, the async call itself may be a work item, as well as
the call's results.

The process method, for an outgoing call, should just perform the async
call, passing a callback for receiving the results.

The callback will be invoked on another thread, which should enqueue a
"result" work item to your main thread's queue.
Your main thread will keep pumping and will eventually pick up the
results and process them

I do not know if such a pattern is suitable for your application
(mainly I don't know what your main thread does !), so take it as it
is, i.e. just another idea

HTH

Claudio Brotto