[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 14:40:51 -0600 |
User-agent: |
Mutt/1.5.9i |
On Thu, Oct 19, 2006 at 04:02:36PM -0400, Chet Ramey wrote:
> Mike Stroyan wrote:
>
> > 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.
> >
>
> Aha! I missed the most relevant call. Now the question is whether or
> not it's still a good idea to pass that 0 from open_shell_script.
Forcing the reuse of an already open file descriptor does seem strange.
I can't think of a situation when that is likely to be better than
using a lower unopened file descriptor or just keeping the original file
descriptor returned by open. If all callers will use a value of 1 you
could just eliminate the "check_new" parameter.
Looking at the other callers, I noticed that the call to
move_to_high_fd() by process_substitute() is using a rather
low value for maxfd.
parent_pipe_fd = move_to_high_fd (parent_pipe_fd, 1, 64);
It will search for an unopened file descriptor between 4 and 64 then
take the highest one it can find. If no file descriptor is unopened
in that range then it will keep using the original file descriptor
returned by pipe(). It doesn't ask to look nearly as high as the
other two callers of move_to_high_fd(). But it is not clear why it
is different.
--
Mike Stroyan, mike.stroyan@hp.com