Re: Using delegates between main/sub threads
On Fri, 09 May 2008 14:35:10 -0700, Ben Voigt [C++ MVP]
<rbv@nospam.nos pamwrote:
>
But by this definition, BeginInvoke is also synchronous.
I can't tell whether you are deliberately or accidently confusing to which
"method" I'm referring, but you are.
Both Invoke() and BeginInvoke() are themselves synchronous. That is,
neither method returns until it's done what it does. All methods are like
this.
However, I'm not talking about those methods. I'm talking about the
method that is invoked by either Invoke() or BeginInvoke(). The docs for
Invoke() don't say that it executes the passed in method asynchronously.
It simply says that it invokes the method on the control's owning thread.
You feel that the fact that the method isn't being invoked on the same
thread that's calling Invoke() means that it's implied that the execution
is asynchronous. While I would be curious if you had an example of some
documentation describing an API that specifically executes a method, does
so asynchronously, and yet the docs don't state that specifically, the
fact is I simply disagree on what's a reasonable assumption or not.
We'll just have to agree to disagree. But in any case, anyone reading the
documentation should be able to follow the logical concusion that, since
Invoke() returns the return value of the method being executed, obviously
it cannot return until that method has itself returned.
It does do exactly that. The use of the word "asychronou sly" isn't
accidental there. It's specifically being used as a shorthand way of
describing what BeginInvoke() does.
That's true. And I wouldn't disagree that the docs would do well to be
more detailed about what BeginInvoke() really is doing. However, the
phrase "executes a delegate asynchronously" is a reasonable approximation
and none of that contradicts what I wrote.
Frankly, I find no productive value in continue to argue about whether the
docs are clear enough or not. If they confuse you, that's fine...please
feel free to suggest to Microsoft that they be improved. There's nothing
wrong with improving documentation, even if they aren't ambiguous as-is.
Pete
On Fri, 09 May 2008 14:35:10 -0700, Ben Voigt [C++ MVP]
<rbv@nospam.nos pamwrote:
>I have no idea what you mean here. If you use Invoke() to call a
>method that updates internal UI state, then when Invoke() returns,
>you can be sure that what that method does -- updating internal UI
>state -- is done. If the method doesn't send a WM_PAINT, then the
>question of when the screen is updated or when a WM_PAINT message
>might be sent is irrelevant. That's not what the method being invoked
>does.
>Don't confuse what a method _does_ with what later implications that
>activity might have. For example, the question of when a WM_PAINT
>message is sent is independent of when a method that updates internal
>UI state is done, and this is true whether you call that method
>directly within the correct thread, or call it indirectly from
>another thread using Invoke().
>method that updates internal UI state, then when Invoke() returns,
>you can be sure that what that method does -- updating internal UI
>state -- is done. If the method doesn't send a WM_PAINT, then the
>question of when the screen is updated or when a WM_PAINT message
>might be sent is irrelevant. That's not what the method being invoked
>does.
>Don't confuse what a method _does_ with what later implications that
>activity might have. For example, the question of when a WM_PAINT
>message is sent is independent of when a method that updates internal
>UI state is done, and this is true whether you call that method
>directly within the correct thread, or call it indirectly from
>another thread using Invoke().
But by this definition, BeginInvoke is also synchronous.
"method" I'm referring, but you are.
Both Invoke() and BeginInvoke() are themselves synchronous. That is,
neither method returns until it's done what it does. All methods are like
this.
However, I'm not talking about those methods. I'm talking about the
method that is invoked by either Invoke() or BeginInvoke(). The docs for
Invoke() don't say that it executes the passed in method asynchronously.
It simply says that it invokes the method on the control's owning thread.
You feel that the fact that the method isn't being invoked on the same
thread that's calling Invoke() means that it's implied that the execution
is asynchronous. While I would be curious if you had an example of some
documentation describing an API that specifically executes a method, does
so asynchronously, and yet the docs don't state that specifically, the
fact is I simply disagree on what's a reasonable assumption or not.
We'll just have to agree to disagree. But in any case, anyone reading the
documentation should be able to follow the logical concusion that, since
Invoke() returns the return value of the method being executed, obviously
it cannot return until that method has itself returned.
It does not do
what the documentation says ("Executes a delegate asynchronously" ),
what the documentation says ("Executes a delegate asynchronously" ),
accidental there. It's specifically being used as a shorthand way of
describing what BeginInvoke() does.
it posts
a request into a queue corresponding to the UI thread, then returns. The
future execution of the delegate identified in that request is merely a
"later implication of that activity".
a request into a queue corresponding to the UI thread, then returns. The
future execution of the delegate identified in that request is merely a
"later implication of that activity".
more detailed about what BeginInvoke() really is doing. However, the
phrase "executes a delegate asynchronously" is a reasonable approximation
and none of that contradicts what I wrote.
Frankly, I find no productive value in continue to argue about whether the
docs are clear enough or not. If they confuse you, that's fine...please
feel free to suggest to Microsoft that they be improved. There's nothing
wrong with improving documentation, even if they aren't ambiguous as-is.
Pete
Comment