On Thu, Nov 03, 2011 at 10:29:48AM +0100, Christian Parpart <[email protected]> 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 <[email protected]> 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 --==---/ / _ \/ // /\ \/ / [email protected] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
