From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
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 BC65E1F462;
	Sat,  1 Jun 2019 22:26:52 +0000 (UTC)
Date: Sat, 1 Jun 2019 22:26:51 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: Re: [PATCH] ds: fix and test for FD leaks with kqueue on ->Reset
Message-ID: <20190601222651.GA56026@ailurophile>
References: <20190601214347.19526-1-e@80x24.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190601214347.19526-1-e@80x24.org>
List-Id: <meta.public-inbox.org>

I forgot to note this drops "support" for libkqueue (which
emulates kqueue using epoll on Linux) because emulating
the unique close-on-fork behavior of kqueue is tricky
and libkqueue currently does not emulate close-on-fork.

Detecting the presence of close-on-fork in libkqueue is
also tricky, but maybe it can be fixed:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929857

So yeah, tt's too time-consuming to ensure libkqueue works
on Linux and ultimately pointless since we already support
epoll.  And I doubt there's any relevant kernels which
aren't covered by native kqueue besides Linux.