On Wed, Nov 2, 2011 at 3:43 PM, Brandon Black <[email protected]> wrote: > > On Wed, Nov 2, 2011 at 6:58 AM, Christian Parpart <[email protected]>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.
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
