On Wed, Nov 2, 2011 at 6:58 AM, Christian Parpart <tra...@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).
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 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. -- Brandon
_______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
