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(
- 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
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
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
7;false' again will break accept_internal() as it was intended to work,
>>>> no ?
>>>>
>>> accept_internal should be unaffected by the default. I think it was
>>> intended to check the value and do something based on it. Otherwise there
>>> should not
>>> no ?
>>>
>> accept_internal should be unaffected by the default. I think it was
>> intended to check the value and do something based on it. Otherwise there
>> should not even be an option to check.
>>
>> The question is what the callers sh
therwise there should not even
be an option to check.
The question is what the callers should do. I can try tweaking TSNetAccept to
turn off frequent_accept, which is original (2.1.6) behavior (although that
seems to make mock of the accept_threads parameter). We're still left with the
ques
is what the callers should do. I can try tweaking TSNetAccept to
turn off frequent_accept, which is original (2.1.6) behavior (although that
seems to make mock of the accept_threads parameter). We're still left with the
question of why my code fails regression with fast accept.
On 1/22/12 7:13 PM, Leif Hedstrom wrote:
Still watching the game at In The Zone, but, with your patch, does it still
support both accept threads (1 or more) and non-blocking accept on each
net-thread ?
So, looking at some older code, v2.1.6 for example, where we passed around
frequent_accep
Still watching the game at In The Zone, but, with your patch, does it still
support both accept threads (1 or more) and non-blocking accept on each
net-thread ?
On Jan 22, 2012, at 5:42 PM, "Alan M. Carroll"
wrote:
> I could be wrong. It happened once before, so why not twice?
>
> Sunday, Ja
I could be wrong. It happened once before, so why not twice?
Sunday, January 22, 2012, 6:10:04 PM, you wrote:
> Hmmm, I'll have to go read the code again, after the 49ers game. That is not
> how I remember it at all.
Hmmm, I'll have to go read the code again, after the 49ers game. That is not
how I remember it at all.
On Jan 22, 2012, at 4:36 PM, "Alan M. Carroll"
wrote:
> Sunday, January 22, 2012, 4:28:27 PM, you wrote:
>
>> Hmmm, this sounds awefully familiar, I think we had this exact problem once
>>
Sunday, January 22, 2012, 5:36:23 PM, you wrote:
> As for accept threads, my reading of the code is that if frequent_accept is
> false, then every normal IO thread also does accepts (via
> NetAccept::init_accept_per_thread).
No, that's wrong. It calls NetAccept::init_accept and starts a single
Sunday, January 22, 2012, 4:28:27 PM, you wrote:
> Hmmm, this sounds awefully familiar, I think we had this exact problem once
> before as well, and I changed it back to "true" as it used to be.
Define "used to be". I specifically checked the 2.1.7 codebase and AFAICT it
used false in all "real
2) Should we just get rid of the fast accept path if it is only used in
examples and testing?
I'm a little confused I think. Looking at the code, frequent_accept also
enables accept threads, and accept per thread. Unless I'm totally wrong, I
think we should get rid of this "
live testing.
I don't know why I haven't seen this effect before, as the default change was
almost 5 months ago.
1) Is there any evidence that the default for frequent_accept (that is, use
fastAccept) should remain true instead of false (do not use)?
2) Should we just get rid of the f
17 matches
Mail list logo
