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

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Wed, 17 Apr 2013 13:11:29 -0400
> 
> On Wed, 2013-04-17 at 19:10 +0300, Eli Zaretskii wrote:
> > That could be a misunderstanding on my part: I didn't realize that by
> > "handle" you mean a FILE object.  I thought you meant Windows specific
> > HANDLE objects (which underly every open file).
> 
> I'm not very familiar with Windows terminology.  Is a HANDLE equivalent
> to a UNIX file descriptor?  Or is it a third thing, different from UNIX
> fd's or C standard FILE*'s?

It is a third thing.  It is a pointer to an opaque object, returned by
the OS primitives that open a file.  The C runtime layer then
maintains an array of structs where it keeps information about each
open file, and an index into that array is the file descriptor.

> > Anyway, I'm not sure why the current code calls tmpfile, which
> > produces a FILE object, but then only uses its file descriptor and
> > read/write functions.  Why not keep the FILE object in the child
> > struct, and use fread/fwrite instead?
> 
> 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.

> Also, a stream is much more resource-heavy than a file descriptor, as it
> implies buffering etc. in addition to the open file.  We wouldn't use
> the buffering, but it's still there.

What's wrong with using the buffering?