Re: sockets : Writing and reading on the same thread with events ?
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sun, 16 Nov 2008 13:00:22 -0800
On Sun, 16 Nov 2008 04:50:42 -0800, Alessandro De Simone <askmeformymail@xxxxxxxxxx> wrote:
Thanks for the answer.
You have to provide a callback, but there's no rule that says you have to do anything in the callback. You could just pass an empty anonymous method, and wait on the handle you get from the IAsyncResult.
Correct me if I'm wrong, but the BeginReceive method use another thread even when you don't specify a callback.
As I mentioned, you _must_ provide a callback. But you're right, the callback will almost always occur on a different thread than that used to call BeginReceive().
The callback is just a delegate called at the end of the thread (potentially in another different thread!). Because you have to call EndReceive, most of the time the callback is very useful.
You don't have to call EndReceive() in the callback. If you are waiting on the event handle returned by the IAsyncResult returned by the call to BeginReceive(), you can simply call EndReceive() in that same thread.
I guess for me the real question is why is it so important that you read and write on the same thread? [...]
I want to have a minimum overhead in my application.
Do not make premature optimizations. They often wind up pointless or even counter-productive, and they cost you development time (design, coding, testing, the whole works).
I don't need to send and read data at the same precise time. I make the assumption that, most of the time (but not every time), a client send a message and wait for an answer before sending another.
How many connections will you have? If just one, then there is no performance optimization you can make that will matter when it comes to network i/o. The cost of the network i/o itself (i.e. the bandwidth of the actual network connection) is so much higher than that of any code that will handle moving the data into or out of that connection that optimizing the latter is pointless.
If (a great deal) more than one, then you must have either a single thread managing multiple connections, or you've got one of these threads per connection. In which case your optimization would be counter-productive. The asynchronous Socket methods use IOCP with a dedicated thread pool, and they are there precisely because that's the most efficient way to deal with network i/o.
So, if a second thread isn't necessary, why should I use it ?
Because it makes your design simpler and works better with the framework's intent. The fact is, one extra thread is not going to produce a significant difference in performance at all, and that's assuming there really is an extra thread (sometimes there would be, sometimes there won't be...it depends on what else is going on in the process). There's absolutely no point in wasting time and energy contorting your application's design to try to avoid that one extra thread. At best, it's a waste of your time, and at worst it could actually reduce your application's performance.
Pete
.
- References:
- sockets : Writing and reading on the same thread with events ?
- From: Alessandro De Simone
- Re: sockets : Writing and reading on the same thread with events ?
- From: Peter Duniho
- Re: sockets : Writing and reading on the same thread with events ?
- From: Alessandro De Simone
- sockets : Writing and reading on the same thread with events ?
- Prev by Date: Re: sockets : Writing and reading on the same thread with events ?
- Next by Date: Profile permission
- Previous by thread: Re: sockets : Writing and reading on the same thread with events ?
- Next by thread: Start a DOS-Process shows no output
- Index(es):
Relevant Pages
|
