From owner-freebsd-hackers  Wed Jul 21 19:10:42 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id 2E51415551
	for <freebsd-hackers@FreeBSD.ORG>; Wed, 21 Jul 1999 19:10:26 -0700 (PDT)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40336>; Thu, 22 Jul 1999 11:51:50 +1000
Date: Thu, 22 Jul 1999 12:10:12 +1000
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Subject: Re: Proposal for new syscall to close files
In-reply-to: <199907220123.VAA32548@bb01f39.unx.sas.com>
To: jwd@unx.sas.com
Cc: freebsd-hackers@FreeBSD.ORG
Message-Id: <99Jul22.115150est.40336@border.alcanet.com.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

"John W. DeBoskey" <jwd@unx.sas.com> wrote:
>   I like this approach. I have a number of often spawned daemon
>processes that could benefit from this.
I don't suppose that you have any statistics showing that the
	for (i = 3; i < getdtablesize(); i++) close(i);
approach would be too slow?

>   For naming convention considerations, I might suggest 'closeall'
>or 'closefdset' or something similar... at least have 'close' in 
>name... :-)

I'm not really keen on the name either - but I couldn't think of
anything better.  `closeall' isn't really descriptive since it doesn't
close all the FDs.  `closefdset' suggests (to me, anyway) the opposite
behaviour: ie closing the FDs specified in the passed fd_set, instead
of closing everything else.

Peter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message