mmhh... I think I should take the pain to experiment a few BeginRead sample,
just to see...
it's just I'm so used to create Thread, it's seems much simple to me, not
too mention the way you could do anonymous method in 2.0!..
Generally, .NET classes that offer a BeginXXX method as an asynchronous
alternative to the XXX mehtod do so because the implementation of their
BeginXXX method is more efficient than creating a thread and calling the
XXX method within it.
I'm not too sure of what happens with the Stream class but if you take the
Socket class for instance, it has a Connect and a BeginConnect methods.
What takes time when connecting to a server is not the processing that you
need to do but the time it takes for your packets to travel across the
network. If you were to create a new thread and simply call the Connect
method within it, then your new thread, which would have required some time
to be created, would basically sit there, waiting for the server answer to
arrive, doing absolutely nothing for most of its lifetime. A big waste of
ressources. If you had called the BeginConnect method instead, this method
would have had issued the required commands to your network adapter and
returned immediately afterwards without waiting for the answer to arrive.
No time waisted in creating a thread. When the server answer would have had
arrived, the network adapter would have notified the Framework in some way
(an interuption maybe), and the Framework would then have taken a thread
from the threadpool (once again, not need to create a new thread) to
execute your callback method. More efficient than manually creating a new
thread that would just wait for something to happen. Actually, once you
played a bit with the BeginXXX methods, you'll find them easier to use than
always having to create your own threads. They also allow you to keep a
consistent coding style when doing asynchronous operations since they all
work in the same way (return an IAsyncResult, take an AsyncCallback and a
state object as parameters).