[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Does HIGH_FD_MAX have to be so low?
From: |
Mike Stroyan |
Subject: |
Re: Does HIGH_FD_MAX have to be so low? |
Date: |
Thu, 19 Oct 2006 13:41:24 -0600 |
User-agent: |
Mutt/1.5.9i |
On Thu, Oct 19, 2006 at 03:33:37PM -0400, Chet Ramey wrote:
> Mike Stroyan wrote:
>
> > Looking at open_shell_script() in shell.c and move_to_high_fd() in
> > general.c, I find that the code will force the use of fildes 255,
> > (HIGH_FD_MAX), for reading the shell script when getdtablesize() reports
> > that the maximum allowed file descriptor value is greater than 255.
> > In this particular case the maximum file descriptor value was 1023,
> > which would have stayed out of the way of the application's use.
>
> If you look closely at move_to_high_fd(), you see that it attempts to
> avoid file descriptors already in use. Only if fcntl(fd, F_GETFD, ...)
> returns -1 does it conclude that file descriptor fd is available.
>
> One can debate whether or not we should be checking explicitly for
> EBADF, but that's the only value of errno that's valid for F_GETFD
> anyway.
>
> I'd be interested in knowing why fcntl didn't return -1, if the parent
> process really did leave the file descriptor open and didn't set the
> close-on-exec flag.
move_to_high_fd() only avoid open file descriptors if the
check_new parameter is non-zero. open_shell_script() calls
move_to_high_fd() with a check_new value of 0. The other two callers
of the function do pass in a check_new value of 1.
--
Mike Stroyan, mike.stroyan@hp.com