Creating child processes - Unix

This is a discussion on Creating child processes - Unix ; Rainer Weikusat wrote: > Rainer Weikusat writes: >> Geoff Clare writes: >>> Rainer Weikusat wrote: >>>> Jaap Bruinsma writes: >>>>> Barry Margolin wrote: >>>>> >>>>>> maxfd = getdtablesize(); >>>>>> for (fd = 3; fd >>>>>> close(fd); >>>>> >>>>> The portable ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: Creating child processes

  1. Re: Creating child processes

    Rainer Weikusat wrote:

    > Rainer Weikusat writes:
    >> Geoff Clare writes:
    >>> Rainer Weikusat wrote:
    >>>> Jaap Bruinsma writes:
    >>>>> Barry Margolin wrote:
    >>>>>
    >>>>>> maxfd = getdtablesize();
    >>>>>> for (fd = 3; fd<=maxfd; fd++)
    >>>>>> close(fd);
    >>>>>
    >>>>> The portable solution would be using sysconf(_SC_OPEN_MAX), instead of
    >>>>> getdtablesize()
    >>>>
    >>>> This isn't necessarily true: sysconf(_SC_OPEN_MAX) may indicate that
    >>>> there is no such limit
    >>>
    >>> On a system where sysconf(_SC_OPEN_MAX) indicates that there is no
    >>> limit, what do you expect getdtablesize() to do (if it exists)?
    >>> It would either have to return -1 to indicate no limit, or return
    >>> INT_MAX. Neither is any more helpful than what sysconf() does.

    >>
    >> So, how does "another subroutine call which doesn't help to solve the
    >> problem, either" make the first subroutine call, which already didn't
    >> help, a more portable way of solving the problem?


    As per David's reply, sysconf() is required by POSIX and getdtablesize()
    is not.

    > Additionally, how does 'sysconf' returning a value not useful to solve
    > the problem on a system without getdtable size make the former a more
    > portable way to solve the problem?


    My point was that there is no reason to prefer getdtablesize() over
    sysconf(_SC_OPEN_MAX) on the grounds of functionality. So portability
    comes down to a simple matter of which function is more standard and/or
    more widely implemented.

    --
    Geoff Clare

  2. Re: Creating child processes

    Geoff Clare writes:
    > Rainer Weikusat wrote:
    >> Rainer Weikusat writes:
    >>> Geoff Clare writes:


    [...]

    >>>> On a system where sysconf(_SC_OPEN_MAX) indicates that there is no
    >>>> limit, what do you expect getdtablesize() to do (if it exists)?
    >>>> It would either have to return -1 to indicate no limit, or return
    >>>> INT_MAX. Neither is any more helpful than what sysconf() does.
    >>>
    >>> So, how does "another subroutine call which doesn't help to solve the
    >>> problem, either" make the first subroutine call, which already didn't
    >>> help, a more portable way of solving the problem?

    >
    > As per David's reply, sysconf() is required by POSIX and getdtablesize()
    > is not.


    [...]

    >> Additionally, how does 'sysconf' returning a value not useful to solve
    >> the problem on a system without getdtable size make the former a more
    >> portable way to solve the problem?

    >
    > My point was that there is no reason to prefer getdtablesize() over
    > sysconf(_SC_OPEN_MAX) on the grounds of functionality. So portability
    > comes down to a simple matter of which function is more standard and/or
    > more widely implemented.


    There is really no difference between the two: Neither of both can
    portably be used to determine a sensible upper limit for the original
    loop.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2