> Peter Jeremy writes:
> > > If it ever gets
> > >committed (I don't think it's particularly useful myself),
> > That's 2 against, 1 (me) for.
>
> Three against.
4 against.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
> Peter Jeremy <[EMAIL PROTECTED]> writes:
> > > If it ever gets
> > >committed (I don't think it's particularly useful myself),
> > That's 2 against, 1 (me) for.
>
> Three against.
4 against.
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body
Peter Jeremy writes:
> > If it ever gets
> >committed (I don't think it's particularly useful myself),
> That's 2 against, 1 (me) for.
Three against.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in t
Peter Jeremy <[EMAIL PROTECTED]> writes:
> > If it ever gets
> >committed (I don't think it's particularly useful myself),
> That's 2 against, 1 (me) for.
Three against.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ha
: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 s
I am not sure I see a need for this syscall...
julian
On Thu, 22 Jul 1999, Peter Jeremy wrote:
> "John W. DeBoskey" 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 t
: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
I am not sure I see a need for this syscall...
julian
On Thu, 22 Jul 1999, Peter Jeremy wrote:
> "John W. DeBoskey" <[EMAIL PROTECTED]> 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 stati
"John W. DeBoskey" 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 con
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 '
"John W. DeBoskey" <[EMAIL PROTECTED]> 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?
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
Ville-Pertti Keinonen wrote:
>Note that there are race conditions in your code.
It was intended as a first cut, rather than tested code. Note that
most of it was lifted from the code for select() and fdcloseexec().
> If it ever gets
>committed (I don't think it's particularly useful myself),
Th
Ville-Pertti Keinonen <[EMAIL PROTECTED]> wrote:
>Note that there are race conditions in your code.
It was intended as a first cut, rather than tested code. Note that
most of it was lifted from the code for select() and fdcloseexec().
> If it ever gets
>committed (I don't think it's particularl
> 3) Close all FDs except the ones you explicitly want to keep. This
>is normally something like:
> for (i = getdtablesize(); --i > 2; )
> close(i);
>The advantage is that you are sure you don't miss any. The
>disadvantage is that it requires a system call for
> 3) Close all FDs except the ones you explicitly want to keep. This
>is normally something like:
> for (i = getdtablesize(); --i > 2; )
> close(i);
>The advantage is that you are sure you don't miss any. The
>disadvantage is that it requires a system call fo
It's fairly common, when spawning new processes, to want to make sure
all unwanted FDs are closed. Currently, the options for doing this are:
1) Use fcntl(fd, F_SETFD, FD_CLOEXEC) to set the close-on-exec flag
when the file is opened/cloned. This may not be practical if the
FD must remain
It's fairly common, when spawning new processes, to want to make sure
all unwanted FDs are closed. Currently, the options for doing this are:
1) Use fcntl(fd, F_SETFD, FD_CLOEXEC) to set the close-on-exec flag
when the file is opened/cloned. This may not be practical if the
FD must remain
18 matches
Mail list logo
