:Hi,
:
: I like this approach. I have a number of often spawned daemon
:processes that could benefit from this. One of the last process
:we debugged where we had unwanted open filedescriptors was in
:programs invoked by the cvs loginfo script.
:
: For naming convention considerations, I might suggest 'closeall'
:or 'closefdset' or something similar... at least have 'close' in
:name... :-)
Well, when I weight the benefit of the savings in overhead for a single
syscall verses a close() loop, and when I weigh the seriousness of
introducing a syscall that would not be portable to other operating
systems, and if I also take into account the work required to deal with
descriptors after forking a daemon.... well, I don't think that adding
a new syscall would be worth the relatively minor benefit nor do I think
the improvement in performance would be noticeable. The benefit isn't
great enough to warrent a new syscall in my view.
I've written a number of forking daemons, most noteable my web server
and my Diablo news transit system.
I just don't think the reduced overhead would be noticeable over simply
calling close(), and I didn't have any problems keeping track of which
file descriptors to close in Diablo (and there could be 100+ descriptors).
Keep in mind that after a fork these descriptors have a ref count > 1,
meaning that the close() syscall is almost free. If you assume 5uS/close
you are still talking quite a bit less then a millisecond to close a
hundred descriptors. And that's pretty much the worst case I can think
of.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
