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
|