Re: [bug #33138] .PARLLELSYNC enhancement with patch

[David Boyce]

On Wed, Apr 17, 2013 at 1:00 PM, Eli Zaretskii <address@hidden> wrote:

> I believe the thinking is that some implementations may have a much

> smaller number of open streams (FILE*) allowed, than open file
> descriptors.  The POSIX standard, for example, allows this:
>
> > Some implementations may limit {STREAM_MAX} to 20 but allow {OPEN_MAX}
> > to be considerably larger.

I'd be surprised if this were a real problem nowadays.  E.g., the
Windows C runtime is documented to allow up to 512 FILE streams, which
can be enlarged to 2048 by calling a function.  The max number of file
descriptors is also 2048.

That's not the way it is on Unix. My understanding, and I believe this applies to all Unix variants, is that because the original stdio FILE structure used an 8-bit int to hold the file descriptor, the number of available streams is <256 always and forever (in 32-bit variants - 64-bit builds fix lots of limits). I don't know of any Unix variants which don't allow at least 1024 descriptors, and some allow the limit to be raised dynamically without bound, but the limit on descriptors *associated with streams* is fixed at 256.

I believe this was all documented in comments in the original patch I sent in.

-David Boyce