[PATCH] ev: fix epoll_init fd leak

[Marc Lehmann]

On Thu, Nov 03, 2011 at 10:29:48AM +0100, Christian Parpart <trapni at gentoo.org> wrote:
> whether bad or not, a library not interfacing with anything SHOULD provide
> a logging API instead of relying on undocumented assumptions.

The logging API is file descriptors 1 or 2 - you can direct them to
wherever you want using dup2 or other means.

This has been in unix for ages, and works reasonably well. It is used by
almost any library out there including, again, your libc. "Hardcoded" so
to say.

Redefining unix will get you nowhere except into trouble.

> 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.

Hard to believe - any sources for the second claim, I want to look at who
recommends this kind of insanity. I bet you just made it up, though.

> the first recommendation however is for safety, e.g. for

And the second one is for.... programmers who like bugs?

> 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.

Good luck in your fight against all the libraries that do it that rely on
POSIX and unix behaviour.

> 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.
> 
> it surely is a micro-optimization, I also did not imply that this will lead
> to better performance,

Of course you did imply that, don't get silly - why mention the high
performance thing otherwise? To impress people about how cool and
professional that company is?

I for one learned that that company has silly coding standards that result
in low-quality software. Best to avoid if possible.

> 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.

Big claim, but can you explain how it fucks up libev's initialisation? The
problem you will face explaining this statement is that libev's
initialisation will work fine...

> as the patch got applied now, someone must have admitted appearantly, so
> there was an insight. thanks though.

There was no (new) insight, there was no admittance - this has been
explainend on this list in an e-mail by me before. Your implications are
childish and arrogant.

Please don't make up bullshit statements - I for one now think you pull
out all your statements out of your ass, where you pulled out the one
above.

In any case, whoeever thinks closing standard file descriptors is somehow
good coding practise, or even useful for something, think again. You have
been warned, and if you later fall into this trap, you got to keep the
pieces.

On Thu, Nov 03, 2011 at 10:29:48AM +0100, Christian Parpart <trapni at gentoo.org> wrote:

Uh, gentoo, why didn't I see that before, that explains the high
performance thing - "we don't know anything about performance, but we
constantly optimise for it".

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\