[PATCH] ev: fix epoll_init fd leak

[Christian Parpart]

On Wed, Nov 2, 2011 at 3:43 PM, Brandon Black <blblack at gmail.com> wrote:
>
> On Wed, Nov 2, 2011 at 6:58 AM, Christian Parpart <trapni at gentoo.org>wrote:
>>
>> I do think a little bit different here. Think of a server app. The app:
>> 1.) first reads config file,
>> 2.) populates internal data structures out of it,
>> 3.) cleans up its environment (including closing inherited fds, including
>> 0,1,2)
>> 4.) initializes its own subsystem, including epoll_create(libev) and its
>> own log targets and listener sockets
>> 5.) runs the loop until exit.
>>
>> This is not a bad behaviour.
>>
>>
> It is arguably bad behavior.  You shouldn't be just closing 0/1/2 as part
> of your daemon init, you should be re-opening them on /dev/null if you have
> nothing more interesting to do with them (arguably, connecting fd#2 to some
> mechanism for capturing error output from other libraries might be more
> robust, but if you want to ignore any stderr generated by other code that's
> fine too).
>

whether bad or not, a library not interfacing with anything SHOULD provide
a logging API instead of relying on undocumented assumptions.

Here's the first random hit I got on google showing an example of using
> freopen() to do this during daemon init.  Countless other examples exist,
> and most real-world daemons do something similar with regard to 0/1/2:
> http://www.itp.uzh.ch/~dpotter/howto/daemonize
>

I did google around a bit too, and yes, it is *recommended* to redirect
0/1/2 to /dev/null, however, it is also recommented at least close 0/1/2 in
the first place. the first recommendation however is for safety, e.g. for
bad libraries just reading from 0 or writing to 1 or 2 instead of providing
a proper logging facility. what a daemon/app itself does is up to the
daemon, but a LIBRARY should never assume such things and force the app
developer to live with that.

p.s.: you wanted a software-example, well, I once worked at a company where
>> resources (like fds)
>> and high performance where treated very precise, keeping fds around for
>> nothing would have been
>> a joke, though, sure, you might work around libev's behaviour.
>>
>>
> Keeping 3 whole fds around pointed at /dev/null is pretty common practice,
> and isn't going to affect your performance, that's just silly premature
> micro-optimization.
>

it surely is a micro-optimization, I also did not imply that this will lead
to better performance, however.I did not say in having no logging mechanism
at all. it's a matter of order what/when to close/clean and open/initialize
that is fucking up libev's initialization wrt epoll_create.

as the patch got applied now, someone must have admitted appearantly, so
there was an insight. thanks though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20111103/4be0b3c2/attachment-0001.html>