Re: WHY they are different when checking concurrent limit?

Hi, On Tue, Nov 10, 2015 at 07:50:56AM +, Zhou,Qingzhi wrote: > Hi?? > Thanks very much. > But I think we can use listener_full instead of limit_listener if we want > wake up the listener when there??s a connection closed. Like in the > beginning of listener_accept: > > if

WHY they are different when checking concurrent limit?

Hi guys: I’m reading the source code of version 1.6.2, in function listener_accept: /* Note: if we fail to allocate a connection because of configured * limits, we'll schedule a new attempt worst 1 second later in the * worst case. If we fail due to system limits or temporary resource *

Re: WHY they are different when checking concurrent limit?

Hi, On Mon, Nov 09, 2015 at 12:46:57PM +, Zhou,Qingzhi wrote: > if (unlikely(actconn >= global.maxconn) && !(l->options & LI_O_UNLIMITED)) { > limit_listener(l, _listener_queue); > task_schedule(global_listener_queue_task, tick_add(now_ms, 1000)); /* try > again in 1 second */ > return; > }

Re: WHY they are different when checking concurrent limit?

Hi： Thanks very much. But I think we can use listener_full instead of limit_listener if we want wake up the listener when there’s a connection closed. Like in the beginning of listener_accept: if (unlikely(l->nbconn >= l->maxconn)) { listener_full(l); return; } WHY not