|
|
Mostly, it's hard to state this is the ONLY case. It matters on who owns the threads and other stuff. It's definitely ONE way 
|
|
|
|
|
Could you show me another way to catch exception from another thread please?
regards,
George
|
|
|
|
|
Indeed, I always put a try/catch in the Main.
|
|
|
|
|
But you can never catch exception from other threads, PIEBALDconsult.
regards,
George
|
|
|
|
|
Hello everyone,
I am learning from,
http://msdn2.microsoft.com/en-us/library/2e08f6yc(VS.80).aspx
two simple questions,
1. For every degelate we defined (just a normal C# delegate, no special, and not special designed for asynchronous method call purpose), BeginInvoke and EndInvoke will be defined automatically for every delegate, right? (just looks like for every class we defined, toString, GetHashCode, etc. are defined automatically?)
2. What are the pros and cons compared with the pattern of using EndInvoke to wait for result and the pattern of using WaitHandle to wait for result. To my points, I think they function the same -- block the execution of current thread/method.
thanks in advance,
George
|
|
|
|
|
Umm there are more options than that, but...
If you wish to limit scope to IAsyncResult w/ EndInvoke and WaitHandle.WaitOne
just using EndInvoke allows you to check the IAsyncResult object to see if it finished, if not run other crap until it is then call EndInvoke
the WaitHandle's WaitOne method will block all execution once called until the delegate returns (doesn't allow for state checking to do bust work)
|
|
|
|
|
Thanks Spacix,
1.
"just using EndInvoke allows you to check the IAsyncResult object to see if it finished, if not run other crap until it is then call EndInvoke", no you can not, EndInvoke will be blocked if the aynchronous call is not completed yet.
2.
From this point, I do not see any different effect of using EndInvoke and WaitHandle.
Any comments?
regards,
George
|
|
|
|
|
George_George wrote: BeginInvoke and EndInvoke will be defined automatically for every delegate, right?
Yes.
George_George wrote: just looks like for every class we defined, toString, GetHashCode, etc. are defined automatically?)
Those are inherited from the base class object.
George_George wrote: What are the pros and cons compared with the pattern of using EndInvoke to wait for result and the pattern of using WaitHandle to wait for result. To my points, I think they function the same
Yes, both method blocks execution of current thread. But WaitHandle.WaitOne() allows you to do some processing before EndInvoke() is called. I prefer to use the 4th method explained in that MSDN article. I will pass a call back method reference and call EndInvoke() in that method.
|
|
|
|
|
Must remember the other execution is stuff not within the thread that the waitone was called on or other processes running on the system.
|
|
|
|
|
Thanks Spacix,
Spacix One wrote: Must remember the other execution is stuff not within the thread that the waitone was called on or other processes running on the system.
Could you describe your above points in some other words please? Sorry my English is not very good and I am very interested to learn from your points.
regards,
George
|
|
|
|
|
Thanks N a v a n e e t h,
N a v a n e e t h wrote: But WaitHandle.WaitOne() allows you to do some processing before EndInvoke() is called
I agree all of your points and they are great! Except the above one, I think EndInvoke can achieve the same effect, e.g. you can do something and then invoke EndInvoke.
So, I think the approach of using EndInvoke and the approach of using WaitHandle are the same (at least from functional and effective perspective)?
regards,
George
|
|
|
|
|
George_George wrote: I think EndInvoke can achieve the same effect, e.g. you can do something and then invoke EndInvoke.
It not same fully even though it looks same. When you use WaitOne(), you are allowed to do some extra processing before EndInvoke() is called. That is WaitOne() will wait until the asynchronous method signals it, then the code will come to the next line where you can do further processing and call EndInvoke(). But if you call EndInvoke() directly, it blocks the current thread until it returns the result. Hence you won't be able to do any further processing outside the asynchronous method.
Hope it's clear.
|
|
|
|
|
Thanks N a v a n e e t h,
I want to confirm with you that we can call EndInvoke even if after the asynchronous method completes to retrieve results, right (in this case, EndInvoke will return immediately)?
regards,
George
|
|
|
|
|
George_George wrote: we can call EndInvoke even if after the asynchronous method completes to retrieve results, right
I am sorry, but I am not getting you. Can you rephrase your question ?
George_George wrote: N a v a n e e t h,
There is no space in my name. It's Navaneeth. I added space simply 
|
|
|
|
|
Thanks Navaneeth,
Sorry for my bad English.
My question is, if we call EndInvoke after the completion of the asynchronous method, EndInvoke will not be blocked and we will get return result from EndInvoke (or exception) without blocking, right?
regards,
George
|
|
|
|
|
Yes. It will be returned immediately.
|
|
|
|
|
Thanks N a v a n e e t h,
Question answered.
regards,
George
|
|
|
|
|
It's recommended that you call EndInvoke for every BeginInvoke called, regardless of whether you wait for completion. The MSDN page (http://msdn2.microsoft.com/en-us/library/2e08f6yc.aspx[^]) clearly says "Always call EndInvoke to complete your asynchronous call.".
1. Any exceptions that occurred in the asynchronous method will be thrown when you call EndInvoke, so if you don't call it, you'll miss those.
2. If the async method has any return values or out/ref parameters, then you'll need to obviously call EndInvoke to get them.
|
|
|
|
|
Good point, Senthil!
Two more comments,
1.
From the link you referred, I can not find words like "Always call EndInvoke to complete your asynchronous call", and it is appreciated if you could point out.
2.
S. Senthil Kumar wrote: 1. Any exceptions that occurred in the asynchronous method will be thrown when you call EndInvoke, so if you don't call it, you'll miss those.
I think you mean some code only calls WaitHandle without calling EndInvoke (WaitHandle is singnalled when asynchronous call completes, and you can have choice to ignore return value by without calling EndInvoke)?
If yes, I think the asynchronous method should be executed in another CLR thread, other than the current thread. Right?
And if any exception occurs in the CLR thread, could be caught in the current thread? I doubt it. Since I think the C# exception handling approach does not allow us to have cross-threads exception handling -- means exception occurs in one thread, and we can catch it in another thread? Any comments?
regards,
George
|
|
|
|
|
George_George wrote: From the link you referred, I can not find words like
Really? Did you try searching for the text? It's there in a small rectangular area titled "Important note".
George_George wrote: If yes, I think the asynchronous method should be executed in another CLR thread, other than the current thread. Right?
Um, but isn't that the very definition of an asynchronous method?
George_George wrote: And if any exception occurs in the CLR thread, could be caught in the current thread? I doubt it. Since I think the C# exception handling approach does not allow us to have cross-threads exception handling -- means exception occurs in one thread, and we can catch it in another thread? Any comments?
Any exceptions that occurred in the asynchronous method will be caught by the .NET framework and will be rethrown in the thread that calls EndInvoke. So yes, the framework does have the ability to handle exceptions across threads.
|
|
|
|
|
Cool, Senthil!
S. Senthil Kumar wrote: Any exceptions that occurred in the asynchronous method will be caught by the .NET framework and will be rethrown in the thread that calls EndInvoke. So yes, the framework does have the ability to handle exceptions across threads.
I think .Net framework does something special here in asynchronous method call. In normal case of multi-threaded programming in C#, the exception thrown from one thread can not be caught from another thread, right?
regards,
George
|
|
|
|
|
George_George wrote: In normal case of multi-threaded programming in C#, the exception thrown from one thread can not be caught from another thread, right?
Yes, because each thread has its own stack and exceptions cannot be propagated across stacks.
|
|
|
|
|
Thanks Senthil,
Your answer is clear.
regards,
George
|
|
|
|
|
hi all
i recently develop a project about E-seal(with office2007 word document), now i get the word file hash value(digest), and i need to put it back to the document, but i donot know which position of document is perfect. it is about the office program, so i use VSTO.
can anybody give prompt in detail
appreciate for any reply
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
