Re: add closefrom() call
On Monday 16 July 2007 02:25:37 pm Julian Elischer wrote:
Peter Jeremy wrote:
On 2007-Jul-15 16:51:38 -0700, Julian Elischer [EMAIL PROTECTED]
wrote:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of syscalls.
Is there any other benefit?
I don't think so.. it's less efficient, and harder to do..
syscalls are not in short supply.
Actually, adding a new fcntl is about the same as adding a new system call
except that you don't have to generate tables, etc. (so it might actually be
simpler). I'm not sure it's such a bad idea to just have a fcntl to get the
max open fd and do the loop in userland so you get better auditing of the
individual close() operations.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On 2007-Jul-15 16:51:38 -0700, Julian Elischer [EMAIL PROTECTED] wrote:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of syscalls.
Is there any other benefit?
--
Peter Jeremy
pgphsTYS4NCig.pgp
Description: PGP signature
Re: add closefrom() call
Peter Jeremy wrote:
On 2007-Jul-15 16:51:38 -0700, Julian Elischer [EMAIL PROTECTED] wrote:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of syscalls.
Is there any other benefit?
I don't think so.. it's less efficient, and harder to do..
syscalls are not in short supply.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
* Julian Elischer [EMAIL PROTECTED] wrote:
Ed Schouten wrote:
Wouldn't it be better to just implement it through fcntl() and implement
closefrom() in libc?
that's a possibility but I personally thing the huge difference in
efficiency
makes it worth putting it in the kernel.
Quite a few programs I know of could really help their startup time with
this as the first thing they do is close the first 2000 file descriptors.
Woops! Sorry for responding this late, but it looks like I didn't
explain myself good enough. Sorry. :) To rephrase myself:
Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the
kernel and make closefrom() a simple libc routine:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
Similar to creat(2).
--
Ed Schouten [EMAIL PROTECTED]
WWW: http://g-rave.nl/
pgpbaZ5KqctbJ.pgp
Description: PGP signature
Re: add closefrom() call
Ed Schouten wrote:
* Julian Elischer [EMAIL PROTECTED] wrote:
Ed Schouten wrote:
Wouldn't it be better to just implement it through fcntl() and implement
closefrom() in libc?
that's a possibility but I personally thing the huge difference in
efficiency
makes it worth putting it in the kernel.
Quite a few programs I know of could really help their startup time with
this as the first thing they do is close the first 2000 file descriptors.
Woops! Sorry for responding this late, but it looks like I didn't
explain myself good enough. Sorry. :) To rephrase myself:
Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the
kernel and make closefrom() a simple libc routine:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
Similar to creat(2).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
* Julian Elischer [EMAIL PROTECTED] wrote:
Ed Schouten wrote:
Woops! Sorry for responding this late, but it looks like I didn't
explain myself good enough. Sorry. :) To rephrase myself:
Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the
kernel and make closefrom() a simple libc routine:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
Compatability with an existing implementation.
--
Ed Schouten [EMAIL PROTECTED]
WWW: http://g-rave.nl/
pgpi3x1Qps6xR.pgp
Description: PGP signature
Re: add closefrom() call
We added it basically because doing all the junk described in previous postings in this thread in userland is a ridiculously huge eyesore that doesn't scale and doesn't make sense when 5 minutes of programming nets you a shiny new system call which does it all for you. If you are worried about optimizing it (which kinda implies a system call anyhow since you aren't doing a context switch for each descriptor), worry about optimizing the kernel implementation of the system call rather then optimizing the unoptimizable userland that eats 300ns+ per descriptor to do the close() instead of the 10ns/descriptor that it takes the kernel to do the close(). -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
Matthew Dillon wrote: We added it basically because doing all the junk described in previous postings in this thread in userland is a ridiculously huge eyesore that doesn't scale and doesn't make sense when 5 minutes of programming nets you a shiny new system call which does it all for you. If you are worried about optimizing it (which kinda implies a system call anyhow since you aren't doing a context switch for each descriptor), worry about optimizing the kernel implementation of the system call rather then optimizing the unoptimizable userland that eats 300ns+ per descriptor to do the close() instead of the 10ns/descriptor that it takes the kernel to do the close(). my thought exactly. I also add that speed IS important in this case as I have seen MANY programs that start up by closing the first 2048 descriptors just in case and I've seen some that do it more than once as they move through to daemon state. These programs have a slow startp due to this (not to mention it's a pain to step past it all when debugging). Julian -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Tue, Jul 10, 2007 at 10:53:02AM -0700, Julian Elischer wrote: Joerg Sonnenberger wrote: On Mon, Jul 09, 2007 at 11:46:14PM -0400, Ighighi wrote: Calling F_MAXFD everytime we close a file descriptor would be heavy having too much fd's. On the other hand, it wouldn't make much a difference to just start from getdtablesize() - 1. I fully agree. That is the second version of closefrom in DragonFly -- for the purpose of libc_r BTW. This is silly.. All the code needed to do this is already in the kernel. It's needed at exit time. Make a syscall as a front end to it and be done with it. As I said -- this was done only in libc_r because of the additional constraints of not closing the internal pipe. For any other use case, I full heartedly agree. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Mon, Jul 09, 2007 at 11:46:14PM -0400, Ighighi wrote: Calling F_MAXFD everytime we close a file descriptor would be heavy having too much fd's. On the other hand, it wouldn't make much a difference to just start from getdtablesize() - 1. I fully agree. That is the second version of closefrom in DragonFly -- for the purpose of libc_r BTW. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
Joerg Sonnenberger wrote: On Mon, Jul 09, 2007 at 11:46:14PM -0400, Ighighi wrote: Calling F_MAXFD everytime we close a file descriptor would be heavy having too much fd's. On the other hand, it wouldn't make much a difference to just start from getdtablesize() - 1. I fully agree. That is the second version of closefrom in DragonFly -- for the purpose of libc_r BTW. This is silly.. All the code needed to do this is already in the kernel. It's needed at exit time. Make a syscall as a front end to it and be done with it. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Fri, 6 Jul 2007, LI Xin wrote: To RW: I have not found a suitable audit event for this, should I create a new event? BTW, I can add an AUE_CLOSEFROM event to OpenBSM. This may require a little work by event consumers who will now need to know about an additional source of implicit closes. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
Robert Watson wrote: The Solaris implementation appears to implement two strategies: (1) If procfs is mounted, list the fd directory to get a list of open fds, then close those by number. (2) If procfs is not mounted, query the number of open fds using the resource limit interface, then sequentially close until the right number close. Hence my question as to whether there's actually a big benefit or not -- do we think closefrom() is a performance-critical function? Nope. I will try to see if we have some way to expose lastfile to userland, or whether we have some better approach to implement this in userland next week if I would have some spare time... Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: add closefrom() call
Date: Mon, 09 Jul 2007 15:00:21 +0800 From: LI Xin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Re: add closefrom() call To: Robert Watson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: FreeBSD Hackers freebsd-hackers@freebsd.org mailto:freebsd-hackers@freebsd.org, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Julian Elischer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Ed Schouten [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 LI Xin wrote: Nope. I will try to see if we have some way to expose lastfile to userland, or whether we have some better approach to implement this in userland next week if I would have some spare time... F_MAXFD is easy to implement... Attached is a diff that should work for CURRENT. I'm working on a 6-STABLE. See closefrom.c for an implementation based on F_MAXFD. Still, it doesn't pay to implement it this way... Calling F_MAXFD everytime we close a file descriptor would be heavy having too much fd's. On the other hand, it wouldn't make much a difference to just start from getdtablesize() - 1. Cheers, -- Xin LI [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! --- src/sys/kern/kern_descrip.c.orig Tue Jul 3 22:27:19 2007 +++ src/sys/kern/kern_descrip.c Mon Jul 9 22:19:35 2007 @@ -623,6 +623,13 @@ vfslocked = 0; fdrop(fp, td); break; + + case F_MAXFD: + FILEDESC_SLOCK(fdp); + td-td_retval[0] = fdp-fd_lastfile; + FILEDESC_SUNLOCK(fdp); + break; + default: error = EINVAL; break; --- src/sys/sys/fcntl.h.orig Wed Apr 7 00:19:49 2004 +++ src/sys/sys/fcntl.h Mon Jul 9 22:26:27 2007 @@ -176,6 +176,9 @@ #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW 9 /* F_SETLK; wait if blocked */ +#if __BSD_VISIBLE +#define F_MAXFD 11 /* return the max open fd (NetBSD) */ +#endif /* file descriptor flags (F_GETFD, F_SETFD) */ #define FD_CLOEXEC 1 /* close-on-exec flag */ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Jul 6, 2007, at 9:57 AM, Julian Elischer wrote: Robert Watson wrote: On Fri, 6 Jul 2007, Julian Elischer wrote: Ed Schouten wrote: * LI Xin [EMAIL PROTECTED] wrote: Here is my implementation for FreeBSD. Some difference between my and DragonFly's implementation: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. Wouldn't it be better to just implement it through fcntl() and implement closefrom() in libc? that's a possibility but I personally thing the huge difference in efficiency makes it worth putting it in the kernel. Quite a few programs I know of could really help their startup time with this as the first thing they do is close the first 2000 file descriptors. The Solaris implementation appears to implement two strategies: (1) If procfs is mounted, list the fd directory to get a list of open fds, then close those by number. (2) If procfs is not mounted, query the number of open fds using the resource limit interface, then sequentially close until the right number close. Hence my question as to whether there's actually a big benefit or not -- do we think closefrom() is a performance-critical function? It's one of those things where it's so simple to do it that it hardly seems worth arguing about the colour, or even whether colour is spelled color or colour. Robert N M Watson Computer Laboratory University of Cambridge So guys, where can I pick up my bike-shed? Bert JW Regeer
Re: add closefrom() call
Hi,
Joerg Sonnenberger wrote:
On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote:
The closefrom() call, available in Solaris, is present in NetBSD since
version 3.0.
It is implemented with the F_CLOSEM fcntl() available since version 2.0.
You could also add a system call like it was done in DragonFly. That
might be even simpler to implement.
Here is my implementation for FreeBSD. Some difference between my and
DragonFly's implementation:
- closefrom(-1) would be no-op on DragonFly, my version would close all
open files (From my understanding of OpenSolaris's userland
implementation, this is Solaris's behavior).
- my version closefrom(very_big_fd) would result in EBADF. I am not
very sure whether this is correct, but it does not hurt for applications
that thinks closefrom() would return void.
To RW: I have not found a suitable audit event for this, should I
create a new event?
Cheers,
--
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
Index: lib/libc/sys/Symbol.map
===
RCS file: /home/ncvs/src/lib/libc/sys/Symbol.map,v
retrieving revision 1.8
diff -u -p -u -r1.8 Symbol.map
--- lib/libc/sys/Symbol.map 5 Jun 2007 08:24:34 - 1.8
+++ lib/libc/sys/Symbol.map 6 Jul 2007 08:38:55 -
@@ -65,6 +65,7 @@ FBSD_1.0 {
clock_gettime;
clock_settime;
close;
+ closefrom;
connect;
dup;
dup2;
Index: sys/kern/init_sysent.c
===
RCS file: /home/ncvs/src/sys/kern/init_sysent.c,v
retrieving revision 1.229
diff -u -p -u -r1.229 init_sysent.c
--- sys/kern/init_sysent.c 4 Jul 2007 22:49:54 - 1.229
+++ sys/kern/init_sysent.c 6 Jul 2007 08:12:02 -
@@ -2,7 +2,7 @@
* System call switch table.
*
* DO NOT EDIT-- this file is automatically generated.
- * $FreeBSD: src/sys/kern/init_sysent.c,v 1.229 2007/07/04 22:49:54 peter Exp $
+ * $FreeBSD$
* created from FreeBSD: src/sys/kern/syscalls.master,v 1.232 2007/07/04
22:47:37 peter Exp
*/
@@ -510,4 +510,5 @@ struct sysent sysent[] = {
{ AS(lseek_args), (sy_call_t *)lseek, AUE_LSEEK, NULL, 0, 0 }, /* 478
= lseek */
{ AS(truncate_args), (sy_call_t *)truncate, AUE_TRUNCATE, NULL, 0, 0 },
/* 479 = truncate */
{ AS(ftruncate_args), (sy_call_t *)ftruncate, AUE_FTRUNCATE, NULL, 0, 0
}, /* 480 = ftruncate */
+ { AS(closefrom_args), (sy_call_t *)closefrom, AUE_NULL, NULL, 0, 0 },
/* 481 = closefrom */
};
Index: sys/kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.312
diff -u -p -u -r1.312 kern_descrip.c
--- sys/kern/kern_descrip.c 3 Jul 2007 21:26:06 - 1.312
+++ sys/kern/kern_descrip.c 6 Jul 2007 08:04:00 -
@@ -989,6 +989,44 @@ fgetown(sigiop)
}
/*
+ * Close many file descriptors.
+ */
+#ifndef _SYS_SYSPROTO_H_
+struct closefrom_args {
+ int fd;
+};
+#endif
+/* ARGSUSED */
+int
+closefrom(struct thread *td, struct closefrom_args *uap)
+{
+
+ return(kern_closefrom(td, uap-fd));
+}
+
+int
+kern_closefrom(struct thread *td, int fd)
+{
+ struct filedesc *fdp;
+ int currfd;
+
+ fdp = td-td_proc-p_fd;
+
+ if (fd fdp-fd_lastfile)
+ return (EBADF);
+ else if (fd 0)
+ fd = 0;
+
+ MPASS(fd = 0);
+
+ while ((currfd = fdp-fd_lastfile) = fd)
+ if (kern_close(td, currfd) == EINTR)
+ return (EINTR);
+
+ return (0);
+}
+
+/*
* Close a file descriptor.
*/
#ifndef _SYS_SYSPROTO_H_
Index: sys/kern/syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/syscalls.c,v
retrieving revision 1.213
diff -u -p -u -r1.213 syscalls.c
--- sys/kern/syscalls.c 4 Jul 2007 22:49:55 - 1.213
+++ sys/kern/syscalls.c 6 Jul 2007 08:12:02 -
@@ -2,7 +2,7 @@
* System call names.
*
* DO NOT EDIT-- this file is automatically generated.
- * $FreeBSD: src/sys/kern/syscalls.c,v 1.213 2007/07/04 22:49:55 peter Exp $
+ * $FreeBSD$
* created from FreeBSD: src/sys/kern/syscalls.master,v 1.232 2007/07/04
22:47:37 peter Exp
*/
@@ -488,4 +488,5 @@ const char *syscallnames[] = {
lseek,/* 478 = lseek */
truncate, /* 479 = truncate */
ftruncate,/* 480 = ftruncate */
+ closefrom,/* 481 = closefrom */
};
Index: sys/kern/syscalls.master
===
RCS file: /home/ncvs/src/sys/kern/syscalls.master,v
retrieving revision 1.232
diff -u -p -u -r1.232 syscalls.master
--- sys/kern/syscalls.master4 Jul 2007 22:47:37 - 1.232
+++ sys/kern/syscalls.master6 Jul 2007 07:41:28 -
@@ -846,5
Re: add closefrom() call
* LI Xin [EMAIL PROTECTED] wrote: Here is my implementation for FreeBSD. Some difference between my and DragonFly's implementation: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. Wouldn't it be better to just implement it through fcntl() and implement closefrom() in libc? -- Ed Schouten [EMAIL PROTECTED] WWW: http://g-rave.nl/ pgpTwA4yjX2Zw.pgp Description: PGP signature
Re: add closefrom() call
LI Xin delphij at delphij.net wrote:
Here is my implementation for FreeBSD. Some difference between my and
DragonFly's implementation:
- closefrom(-1) would be no-op on DragonFly, my version would close all
open files (From my understanding of OpenSolaris's userland
implementation, this is Solaris's behavior).
- my version closefrom(very_big_fd) would result in EBADF. I am not
very sure whether this is correct, but it does not hurt for applications
that thinks closefrom() would return void.
Why not follow current practice and return EBADF for -1 ?
It'd be dangerous to close all open files with -1 (a closefrom(0)
would suffice),
and weird to ignore very_big_fd.
I also agree that using fcntl() would be better.
Here's the code I'm using to emulate this call on FreeBSD = 5.0 anyway.
int closefrom(int lowfd)
{
int mib[2] = { CTL_KERN, KERN_FILE };
struct xfile *files = NULL;
pid_t pid = getpid();
int i, nfiles;
size_t fsize;
for (;;) {
if (sysctl(mib, 2, files, fsize, NULL, 0) == -1) {
if (errno != ENOMEM)
goto bad;
else if (files != NULL) {
free(files);
files = NULL;
}
}
else if (files == NULL) {
files = (struct xfile *) malloc(fsize);
if (files == NULL)
return -1;
}
else
break;
}
/* XXX This structure may change */
if (files-xf_size != sizeof(struct xfile) ||
fsize % sizeof(struct xfile))
{
errno = ENOSYS;
goto bad;
}
nfiles = fsize / sizeof(struct xfile);
for (i = 0; i nfiles; i++)
if (files[i].xf_pid == pid files[i].xf_fd = lowfd)
close(files[i].xf_fd);
free(files);
return 0;
bad:
if (files != NULL) {
int save_errno = errno;
free(files);
errno = save_errno;
}
return -1;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Fri, Jul 06, 2007 at 12:50:17PM +0100, Robert Watson wrote: Solaris side-steps this issue by simply auditing the individual close() system calls. My preference would be that we implement this in user space also, which would likewise generate a series of audit events, one for each system call. The procfs optimization they use (I wonder -- is it really an optimization?) won't work for us, however. Do you think that there's a strong motivation to provide a closefrom(2) system call, rather than a closefrom(3) library call? This would let us neatly avoid the question you've posed :-). I can think of at least one possible scenario where it makes a difference: multi-threaded applications with concurrent open/closefrom calls. I would expect the kernel version to ensure that all open files start from the given file descriptor. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Fri, Jul 06, 2007 at 06:18:14PM +0800, LI Xin wrote: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). I think this is a bad idea as -1 is generally an invalid file descriptor. - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. I don't think this is a good idea either. One typical use is closefrom(3) and returning an error because no such descriptors are open sounds very wrong. It also just adds another special case as the loop handles this already Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote: It is implemented with the F_CLOSEM fcntl() available since version 2.0. I don't like the fcntl(2) approach as it applies actions to more than the passed in fd. That feels like an interface abuse. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
Ed Schouten wrote: * LI Xin [EMAIL PROTECTED] wrote: Here is my implementation for FreeBSD. Some difference between my and DragonFly's implementation: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. Wouldn't it be better to just implement it through fcntl() and implement closefrom() in libc? that's a possibility but I personally thing the huge difference in efficiency makes it worth putting it in the kernel. Quite a few programs I know of could really help their startup time with this as the first thing they do is close the first 2000 file descriptors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
On Fri, 6 Jul 2007, Julian Elischer wrote: Ed Schouten wrote: * LI Xin [EMAIL PROTECTED] wrote: Here is my implementation for FreeBSD. Some difference between my and DragonFly's implementation: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. Wouldn't it be better to just implement it through fcntl() and implement closefrom() in libc? that's a possibility but I personally thing the huge difference in efficiency makes it worth putting it in the kernel. Quite a few programs I know of could really help their startup time with this as the first thing they do is close the first 2000 file descriptors. The Solaris implementation appears to implement two strategies: (1) If procfs is mounted, list the fd directory to get a list of open fds, then close those by number. (2) If procfs is not mounted, query the number of open fds using the resource limit interface, then sequentially close until the right number close. Hence my question as to whether there's actually a big benefit or not -- do we think closefrom() is a performance-critical function? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
Robert Watson wrote: On Fri, 6 Jul 2007, Julian Elischer wrote: Ed Schouten wrote: * LI Xin [EMAIL PROTECTED] wrote: Here is my implementation for FreeBSD. Some difference between my and DragonFly's implementation: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. Wouldn't it be better to just implement it through fcntl() and implement closefrom() in libc? that's a possibility but I personally thing the huge difference in efficiency makes it worth putting it in the kernel. Quite a few programs I know of could really help their startup time with this as the first thing they do is close the first 2000 file descriptors. The Solaris implementation appears to implement two strategies: (1) If procfs is mounted, list the fd directory to get a list of open fds, then close those by number. (2) If procfs is not mounted, query the number of open fds using the resource limit interface, then sequentially close until the right number close. Hence my question as to whether there's actually a big benefit or not -- do we think closefrom() is a performance-critical function? It's one of those things where it's so simple to do it that it hardly seems worth arguing about the colour, or even whether colour is spelled color or colour. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add closefrom() call
Ighighi Ighighi wrote: The closefrom() call, available in Solaris, is present in NetBSD since version 3.0. It is implemented with the F_CLOSEM fcntl() available since version 2.0. I think it might worth an effort (sendmail and perhaps some part of JDK uses it IIRC), but I do not want to rush it into -CURRENT unless we have test cases to make sure that we have done things correctly, because I do not have a NetBSD nor Solaris box at hand to experiment its behavior... :-( Do you have some test cases for this? Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: add closefrom() call
On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote: The closefrom() call, available in Solaris, is present in NetBSD since version 3.0. It is implemented with the F_CLOSEM fcntl() available since version 2.0. You could also add a system call like it was done in DragonFly. That might be even simpler to implement. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
