Re: Control.BeginInvoke is NOT fire-and-forget
- From: "Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx>
- Date: Wed, 9 Jul 2008 08:41:10 -0500
Peter Duniho wrote:
On Tue, 08 Jul 2008 08:25:37 -0700, Ben Voigt [C++ MVP]
<rbv@xxxxxxxxxxxxx> wrote:
As much as the CLR team assures us that it's ok to fire-and-forget
Control.BeginInvoke, it seems it isn't. Maybe this is a bug.
See for example: the comments in
http://blogs.msdn.com/cbrumme/archive/2003/05/06/51385.aspx
[...]
Do you think this is a CLR bug or it is by design?
First thing to keep in mind: the assertion about Control.EndInvoke()
has to do with resource cleanup and whether one is required to call
that method to ensure things are cleaned up. It's not about whether
Control.BeginInvoke() will work.
Second, it would be helpful if you'd actually post a
concise-but-complete code sample that reliably demonstrates the
problem. Saying "I original had c.BeginInvoke in the asynchronous
method" doesn't tell us much about how you actually used it or what
might have been going wrong.
Did I write that? Sure enough.
I should have said "in the anonymous method".
i.e. changing the line from
helper.postProcessing = delegate { c.Invoke(finalProcessing); };
back to
helper.postProcessing = delegate { c.BeginInvoke(finalProcessing); };
breaks things, in that the finalProcessing MulticastDelegate never runs nor
throws an exception.
I am relatively confident that if you call BeginInvoke() from a thread
that exits before the invoked delegate gets to run, the invoked
delegate should still run. I would be very surprised if that wasn't
actually what happened. On the other hand, if the thread that _owns_
the control being used to call BeginInvoke() exits or is otherwise
terminated, I would _not_ expect the delegate being invoked to
execute, since it has to execute on that thread.
The control should be owned by the original thread which does not exit, I
read the Handle property for the explicit purpose of forcing it to be
created on that thread, before I spawn the worker.
Again, a complete code sample would eliminate these ambiguities in
your comment. It's impossible to tell for sure from the code you
posted what exactly you were trying to do and what broke. It also
doesn't help that the code you posted is clearly a corner case,
whatever else might have been going on, and you didn't post enough to
show us that you've correctly set the threading model for whatever
threads wind up with a message pump (something that could also break
things).
Changing the call in the asynchronous method which is called at the very end
of the worker threadproc from BeginInvoke to Invoke does cure the problem.
I think this demonstrates that the thread on which the control is created is
properly pumping messages.
Given the evidence so far, I cannot imaging being able to confidently
say there's a bug, whether in the CLR or (as is probably more likely,
assuming this is a bug at all) in the framework.
True, it's most likely a bug in the base class libraries, not the CLR. My
poor wording.
Pete
.
- Follow-Ups:
- Re: Control.BeginInvoke is NOT fire-and-forget
- From: Peter Duniho
- Re: Control.BeginInvoke is NOT fire-and-forget
- References:
- Control.BeginInvoke is NOT fire-and-forget
- From: Ben Voigt [C++ MVP]
- Re: Control.BeginInvoke is NOT fire-and-forget
- From: Peter Duniho
- Control.BeginInvoke is NOT fire-and-forget
- Prev by Date: Re: Sort a char array case-insensitively
- Next by Date: Re: Need Algorithm or Data Structure for Organizing "Hierarchical" Data
- Previous by thread: Re: Control.BeginInvoke is NOT fire-and-forget
- Next by thread: Re: Control.BeginInvoke is NOT fire-and-forget
- Index(es):
Relevant Pages
|
