lkml.org 
[lkml]   [2002]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectepoll (was Re: [PATCH] async poll for 2.5)
Mark Mielke wrote:

>Not to enter into any of the other discussions on this issue, I wouldn't
>usually do what you suggest above. [...] if I did I
>a recv() or read() of 2K, and I only received 1K, there is no reason why
>another system call should be invoked on the resource that likely will not
>have any data ready.
>
>
You're into the minutiae here. Sure, you can optimize the read() in
some cases, but Mr. Libenzi's example of a correct code scheme is no
better than mine when it comes to this.

In some situations, I've found that optimizing in the other direction is
useful. When a peer is feeding you data slowly you can increase
throughput by having the thread block on read for a couple of
milliseconds before going back to the pool. A large part of that was
that the particular event delivery subsystem was expensive.

[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2005-03-22 13:30    [from the cache]
©2003-2011 Jasper Spaans