Sunday, January 22, 2012, 10:20:58 PM, you wrote:
> if (frequent_accept) { // true
I read that as "checking to see if frequent_accept is true".
> What's semi confusing is that the declaration of accept_internal() has the
> frequent_accept parameter defaulted to "false", yet, as far as I c
On 1/23/12 7:57 AM, Alan M. Carroll wrote:
Sunday, January 22, 2012, 10:20:58 PM, you wrote:
if (frequent_accept) { // true
I read that as "checking to see if frequent_accept is true".
Right, and it used to be always true. And you are suggesting to change it to
"false", no ?
What
I think Leif has it right about the use cases and meaning of
frequent_accept. Given how much has changed kernel-wise since that code
was originally written, it isn't clear how much we save by limiting some
accepts to a single thread non-blocking (i.e. epoll() makes the marginal
cost of another fd
On Linux, FreeBSD and Solaris (at least), even with the most recent nonblocking
kernel facilities, it is still faster to accept new TCP connections in a
blocking fashion via thread pool. FWIW.
--
Theo Schlossnagle (mobile)
http://omniti.com/is/theo-schlossnagle
On Jan 23, 2012, at 1:19 PM, John
On 1/23/12 11:21 AM, Theo Schlossnagle wrote:
On Linux, FreeBSD and Solaris (at least), even with the most recent nonblocking
kernel facilities, it is still faster to accept new TCP connections in a
blocking fashion via thread pool. FWIW.
That definitely was the case when we worked on Accept
On 1/23/12 11:21 AM, Theo Schlossnagle wrote:
On Linux, FreeBSD and Solaris (at least), even with the most recent nonblocking
kernel facilities, it is still faster to accept new TCP connections in a
blocking fashion via thread pool. FWIW.
That definitely was the case when we worked on Accept
I think if we switch to fine-grained locking and away from large-grained
try-locks we could deal with the latency issue and get the most out of the
accept thread since we could synchronise between the accept and net threads
faster. This is likely to be easier with a simplified codebase as well.
On
- Original Message -
> I think if we switch to fine-grained locking and away from
> large-grained
> try-locks we could deal with the latency issue and get the most out
> of the
> accept thread since we could synchronise between the accept and net
> threads
> faster. This is likely to be e
Monday, January 23, 2012, 12:19:00 PM, you wrote:
> The key question is "why is the test failing", and AFAICT it looks like
> NetAccept::init_accept() isn't doing:
> PollDescriptor *pd = get_PollDescriptor(t);
> if (a->ep.start(pd, a, EVENTIO_READ) < 0)
> link in init_accept_per_thread(
