On Tue, 27 Mar 2007 18:03:32 -0700, mk <mk@discussions .microsoft.com>
wrote:
I should probably add, the delegates are added to an available pool of
delegates, when they are assigned they are removed from the pool. when
work is complete and the callback is invoked, the delegate is added back
to the pool and may now be reused by other pending items. I am
particularly concerned that exceptions could prevent the callback from
taking place and therefore leak resources, not to mention that the
delegate would never return to the available pool.
I'm not sure what you mean there. A delegate isn't a resource that can be
consumed. It's simply a way of describing a method to be called. There
should be no need to manage the allocation of delegates or to maintain any
sort of pool of delegates. You can keep as many references to the same
delegate as you like, and call any of those references any time you like
(within the usual rules of using a delegate, of course).
Since there's no need to manage a pool of delegates, there is also no
concern about whether an exception will result in a delegate not being
returned to the pool.
As for your original question, it's not very clear what it is exactly you
mean to do. However, generally speaking any limitations regarding queuing
of asynchronous methods would be dependent on your own implementation of
that. One common way to process tasks asynchronously is to use the
BackgroundWorke r class, and in that case the only real limitation there is
how many threads can actually be active concurrently. If you reach that
limit, new work items are queued.
Perhaps you should look at the kind of functionality BackgroundWorke r
gives you, try to actually implement your code using that, and then if you
run into problems post new questions in this newsgroup (or even better,
the microsoft.publi c.dotnet.framew ork newsgroup, since it doesn't appear
your question is actually C#-specific), including more details about what
you're actually doing than you've provided so far.
Pete
