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,AWL,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 3538B1FD45 for ; Thu, 9 Jan 2020 11:14:52 +0000 (UTC) From: Eric Wong To: meta@public-inbox.org Subject: [PATCH 0/3] improve error handling for rare cases Date: Thu, 9 Jan 2020 11:14:49 +0000 Message-Id: <20200109111452.14556-1-e@yhbt.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: I tend to configure high RLIMIT_NOFILE limits, and the default /proc/sys/fs/epoll/max_user_watches is difficult to hit, so I've never hit the errors these patches supposedly fix... But, I've noticed there's a places were we could die() without an eval{} to trap it. These patches fix some of those. On a side note, we still lack sufficient testing for rare error conditions. These errors are not easy to reproduce, especially EPOLL_CTL_ADD failures. Also, the IO::KQueue->EV_SET calls actually make calls to kqueue(2) directly (working more like epoll_ctl), so those could die() inside the emulated epoll_ctl... Another day Eric Wong (3): listener: EPOLL_CTL_ADD errors are non fatal http: log response_write errors qspawn: catch transient errors on pipe, EPOLL_CTL_ADD lib/PublicInbox/HTTP.pm | 5 ++++- lib/PublicInbox/Listener.pm | 3 ++- lib/PublicInbox/Qspawn.pm | 29 ++++++++++++++++++----------- 3 files changed, 24 insertions(+), 13 deletions(-)