From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 0C31B1F461; Mon, 13 May 2019 01:51:34 +0000 (UTC) Date: Mon, 13 May 2019 01:51:33 +0000 From: Eric Wong To: yahns-public@yhbt.net Subject: Re: [RFC/WIP] support non-blocking listeners, too Message-ID: <20190513015133.jtknn3gdp6gydl7g@dcvr> References: <20190511121045.maebjf2wc4h4ljrs@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190511121045.maebjf2wc4h4ljrs@dcvr> List-Id: Eric Wong wrote: > While a major design factor of this server was based > load-balancing with blocking accept() in a dedicated thread, > non-blocking accept() has become fairer with EPOLLEXCLUSIVE in > Linux 4.5+. Actually... not sure if it matters, even. EPOLLEXCLUSIVE still seems worse off than a blocking accept4() thread. The process which gets woken from epoll_wait can still be stuck dealing with application processing or other I/O (the kernel has no way of knowing that). Blocking on accept4() is fairer in that regard since it round-robins the processes. On a related note, having a multi_accept parameter (like nginx) should be beneficial to single-process deployments.