Re: Uniquely Identifying Multiple/Concurrent Async Tasks
- From: Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Fri, 14 Sep 2007 21:17:51 -0700
Frankie wrote:
The identifier wouldn't necessarily be used to look up data [related to the operation].
Okay.
The identifier would identify the specific instance of the operation, itself.
For what purpose do you need to identify the specific instance of the operation? If you are not going to use the identifier as a way of correlating the operation with some other data, why do you need it at all?
There's no reason that we _must_ associate any data with an async operation... just have it go to work. I would agree with the position that states we would _usually_ have data to associate with an async operation, and therefore could/should use that to ID the operation as you are suggesting.
You are right that there's no reason you must associate any data with an async operation. But if there's no data associated with it, what need for an identifier exists?
But what does "identifying" which operation has completed gain you? The identification does you no good unless you somehow correlated the identification with some data specific to the operation. So you might as well use the data itself as your unique identifier.
Yes, but that's assuming that data must or can be associated with an async operation prior to initiating it.
Or as part of initiating it, anyway.
Can't we have async operations without associated data?
Sure, no reason you can't have that.
We can certainly have methods that return void and take zero parameters. They just "do something". What's to say we can't call such a method asynchronously?
Nothing at all. But if that's all you have, why do you need an identifier?
At the bottom of this post I have a more detailed example. The information we might want from such an asynchronous call might include things about the call, itself, which might not be available before calling the method. Such data about the call, itself, might include things like "user cancelled the operation before it completed", "operation ran into Exception xyz during the course of its operations", or "the operation just now completed." In these cases, we'd have to invent some identifier out of thin air - perhaps a unique integer, which is what I was thinking in the OP here. Maybe I'm still wrong about that.
My previous comments have related primarily to data specific to the client of the task. You have mentioned above things which may be specific to the class implementing the task, and I agree that's not data that the client should have to instantiate.
But that doesn't mean that the data isn't instantiated somewhere.
If what you want is a way for the client to retrieve information about the task, it seems to me that the model there would be to have the task itself represented by a class, returned by the method that starts the asynchronous task. That class could implement IAsyncResult if you like, but of course there's no _requirement_ that async operations follow the ..NET IAsyncResult pattern.
[...]
All the client app will do is kick off these ValidateAsync operations which will in turn report (1) progress (i.e., "SomeWebSite.com validated successfully", or "failed to connect to TheDbNamedX" etc - for each Web site and for each db), and (2) report when each ValidateAsync operation completes (including the usual AsycnCompletedEventArgs stuff). In this scenario I'm not sure how the client app that initiates these ValidateAsync operations would identify each async operation without assigning some unique ID invented out of thin air.
Well, that brings me back to my previous question. What would you use the ID for? Why does the client need to identify each async operation? And why can that identification not be accomplished via an instance of some class that specifically refers to the operation in some way?
The async patterns in .NET I'm most familiar with are the Begin/End pattern that involves IAsyncResult, and the BackgroundWorker class that uses events. It's not entirely clear from your post which you are proposing, but the above suggests you are doing an event-based design.
If you have a need for the client to retrieve information about the task before it's completed, then I would say having the async method returning a class that provides for this (in the form of properties, for example) would be appropriate. This class could also be included by reference in your EventArgs class, so that the event handler also had easy access to the task information.
Still, in the end you don't need an ID. You need some kind of reference to the data you are trying to get.
If you feel that there's a use for an ID for a purpose other than retrieving data (including state information), then I'd say you still haven't been clear about how that would work, or what purpose that would be. I'm a little tired at this point, so maybe I'm missing some obvious point. But whatever the reason, I seem to need a more basic, fundamental description in order for me to understand what the need for a numeric ID is.
Pete
.
- References:
- Re: Uniquely Identifying Multiple/Concurrent Async Tasks
- From: Peter Duniho
- Re: Uniquely Identifying Multiple/Concurrent Async Tasks
- From: Peter Duniho
- Re: Uniquely Identifying Multiple/Concurrent Async Tasks
- Prev by Date: Flickering
- Next by Date: Re: Syntax Question - meaning of tilde (~)
- Previous by thread: Re: Uniquely Identifying Multiple/Concurrent Async Tasks
- Next by thread: Re: Uniquely Identifying Multiple/Concurrent Async Tasks
- Index(es):
Relevant Pages
|
