BeginInvoke returns an IAsyncResult, but in cases where the caller doesn't
care and couldn't do anything even if it did care, I don't assign the
returned value and assumed it would be garbage-collected.

Some bloggers say that this pattern leaks resources.

MSDN doesn't seem to see a problem with this pattern, so I wonder.

How to: Use a Background Thread to Search for Files
http://msdn2.microsoft.com/en-us/library/3s8xdz5c(VS.80).aspx
Example code has several calls to BeginInvoke and no calls to EndInvoke.
(Unlike my code this example uses the returned IAsyncResult, but this
example still doesn't call EndInvoke.)

Control.BeginInvoke Method (Delegate, Object[])
http://msdn2.microsoft.com/en-us/library/a06c0dc2(VS.80).aspx
Example code discards the returned IAsyncResult just like mine, and doesn't
call EndInvoke.

Of course in many situations it's not advisable to omit things like error
checking, but there's no point in my situation. The caller is a thread that
can't reasonably display UI. The target is a UI thread and it immediately
informs the user if it detects a problem.

So my concern is just whether this pattern is reliable or not. Will it leak
resources as some bloggers say? Or is it OK as MSDN seems to suggest?

[quoted text, click to view]

In principle, it might at least *temporarily* leak resources. It
depends on the implementation. However, the Windows Forms team has
guaranteed that Control.BeginInvoke doesn't need a matching EndInvoke
call.

If you want "fire and forget" semantics you can use the class
implemented here:

http://www.yoda.arachsys.com/csharp/threads/threadpool.shtml

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet

[quoted text, click to view]

Thank you for responding, but I'm having trouble figuring out the answer(s).

In principle there might be resource leaks which might be at least
temporary, which means there's a chance the leaks might grow until the
process exits? So some bloggers are correct and MSDN (at least the two
pages which I cited last time) is wrong?

However, Control.BeginInvoke doesn't need a matching EndInvoke call for
which reason: because there is no leak, or because the leak is temporary
until garbage collection, or the leaks accumulate until the process exits
but luckily no one (including me so far) has been damaged by the leaks
accumulating too enormously?

[quoted text, click to view]

Thank you. But I still don't understand: do I *need* the class that is
implemented there?

Again, in my situation I'm calling BeginInvoke on a private method in a
form, so the callee is running in the UI thread and if any errors occur
that's the time they're displayed. The caller is in a background thread
which is about to exit, it cannot do anything with a return value or any
other information, so "fire and forget" is suitable.

[quoted text, click to view]

Depending on the implementation of the IAsyncResult, a half-called async
method could leak synchronization primitives. They should be cleaned up
by the finalizer eventually, assuming that the finalizer thread isn't
blocked for some reason (some buggy finalizer somewhere). However,
synchronization primitives (usually) are OS resources and there are
performance concerns with keeping too many of them around. If you have a
server app which leaks them with abandon, far more of them will be alive
at any one time that necessary.

-- Barry

--

[quoted text, click to view]

It's likely that finalizers will free up the resources, so they don't
leak as such (assuming things have been robustly implemented, of
course) - but the resources they temporarily hold might be required
*before* the finalizer is executed.

[quoted text, click to view]

BeginInvoke is implemented in Windows Forms has been implemented in
such a way that there's no leak, in my understanding.

[quoted text, click to view]

That depends on whether you're using Control.BeginInvoke or a delegate
BeginInvoke.

[quoted text, click to view]

If you're using Control.BeginInvoke, you don't need to worry.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet

On Wed, 26 Dec 2007 16:21:11 -0800, Norman Diamond
[quoted text, click to view]

Good, my turn to confuse matters (i.e. create a mess that Jon has to clean
up :) ).

[quoted text, click to view]

The first paragraph is correct for sure. I remain unconvinced that it's
untrue for Control.BeginInvoke(), at least as an unqualified statement.

Consider the statement in the doc page for IAsyncResult.AsyncWaitHandle:

Notes to Implementers The object that implements IAsyncResult
does not need to create the WaitHandle until the AsyncWaitHandle
property is read. It is the choice of the IAsyncResult
implementer. However, if the implementer creates AsyncWaitHandle,
it is the responsibility of the implementer to signal the
WaitHandle that will terminate the wait at the appropriate time.
For example, System.Runtime.Remoting.Messaging.AsyncResult
terminates the wait on behalf of the caller when an asynchronously
invoked method returns. Once created, AsyncWaitHandle should be
kept alive until the user calls the method that concludes the
asynchronous operation. At that time the object behind
AsyncWaitHandle can be discarded.

In other words, if the caller to Control.BeginInvoke() actually uses the
AsyncWaitHandle from the IAsyncResult it gets from Control.BeginInvoke(),
then that WaitHandle (which implements IDisposable and so must be disposed
when it's no longer needed) is required to be kept until the "_user_
[emphasis mine] calls the method that concludes the asynchronous
operation". In other words, the user's code has every reason to expect
that the WaitHandle will remain valid until that code calls
Control.EndInvoke().

So code that gets the AsyncWaitHandle is going to have to call EndInvoke()
to ensure they clean up that resource properly (EndInvoke() baing "the
method that concludes the asynchronous operation".

Beyond that, even if you can show in the current Control implementation
that there's no harm in not calling Control.EndInvoke(), I would say that
absent some clear, explicit statement in the MSDN documentation pages that
says that you don't need to call EndInvoke(), that pairing the two calls
may well be important, and very much _should_ be assumed to be so, at
least if your code uses the AsyncWaitHandle in the IAsyncResult, if not in
other cases.

I've looked for such a clear, explicit statement and haven't been able to
find one.

I'm carefully ignoring the fact that Control.BeginInvoke() doesn't follow
the normal pattern for async methods. There's no way to specify a
callback, never mind a context/state object for the callback. This means
it's practically impossible for the asynchronously invoked method to have
access to the IAsyncResult (it's not literally impossible, but it's
impractical because any attempt to provide access results in a race
condition...that can be addressed by adding thread synchronization, but
then that seems to me to negate the whole point of using BeginInvoke() in
the first place).

This means that if you _do_ call EndInvoke() you have to do it somewhere
other than the invoked delegate. This leads to inelegant things like
polling IAsyncResult.IsCompleted, or just calling EndInvoke() and possibly
getting blocked anyway. I suppose there are situations where this is
actually what you'd want to do, but being forced into seems kind of ugly
to me.

In other words, it bugs me that the whole Control.BeginInvoke() API is the
way it is. While I can understand the need for backward compatibility, I
don't understand why it remains in this sort of awkward state rather than
adding some overloads to Control.BeginInvoke() to allow it to be used in a
more typical fashion.

[quoted text, click to view]

I suspect that as long as you do nothing with the IAsyncResult returned by
BeginInvoke(), you're fine. But I wish there was some more explicit
documentation to that effect.

[quoted text, click to view]

One feature of delegates is that they are not specific to whatever method
they might be passed to. You can create a single delegate that is
suitable for either Control.BeginInvoke() or Delegate.BeginInvoke() (and
for the synchronous Invoke() equivalents as well). The delegate does not
need to be related to the Control class at all, never mind be an instance
member, or a member of any Control-derived class of any sort.

The corollary is that the delegate itself doesn't "know whether to be"
anything in particular, nor does it need to. The sole determining factor
is how you use it If you call Control.BeginInvoke(), then it's used by
Control.BeginInvoke(), executed on that Control instance's owning thread.
If you call Delegate.BeginInvoke() on the delegate instance itself, then
it's invoked asynchronously via that method.

On Wed, 26 Dec 2007 19:05:36 -0800, Norman Diamond
[quoted text, click to view]

While I like good sample code, it's no substitute for actual
documentation. If nothing else, I have seen MSDN code samples that I know
for a fact are wrong. Documenting by example doesn't work very well,
regardless.

[quoted text, click to view]

For what it's worth, calling sleep is not a good way to address a race
condition. It may reduce the chances of a problem, but it's not a good
way to eliminate the chances. You either need to synchronize your
threads, or just allow the race to occur and handle it gracefully.

[quoted text, click to view]

They are created by the compiler, but they aren't fictions. Not as far as
I know, anyway. My understanding is that they are considered part of the
Delegate class, even though they are compiler-dependent. Anyway, writing
"Delegate.BeginInvoke()" seems easier to me that some alternative
description, even if technically the method's not part of the class. :)

[quoted text, click to view]

If the code calling Control.BeginInvoke() is an instance member of a
Control-derived class, then yes...if you call "this.BeginInvoke()" you are
definitely calling Control.BeginInvoke(). Of course, you don't actually
need the "this." part.

Since Form inherits Control, any Form-derived class you write will behave
like this. This is basic C#/OOP behavior...don't let the fact that you're
dealing with this funny BeginInvoke() pattern make you think that it
doesn't otherwise work like any other call. The funny business happens in
the parameters for the method, not the call to the method itself. :)

OK, I think this makes things clearer.

Calling BeginInvoke on an "ordinary" delegate, without calling EndInvoke,
can cause resource usages to hang around longer than necessary (until the
next garbage collection), which can cause temporary starvation in a server
or other victim when a heavy user of resources is present. However, there's
no permanent leak.

Calling BeginInvoke on Control, without calling EndInvoke, doesn't even have
that problem.

There are 8,192 executions of BeginInvoke in the situation I'm presently
concerned with, so I think that temporary starvation isn't happening, and
nothing worse can happen.

I still have some curiosity remaining from a former not-having-a-life as a
language lawyer. When I create a delegate that points to a private method
in a form, the form inherits from Control. But how is that enough to make
the delegate know whether to be a Control.something (with method
Control.BeginInvoke) or an "ordinary" delegate (with method
somethingelse.BeginInvoke)?


[quoted text, click to view]