[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Smith
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
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?

> 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.

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.  We might need two different temp
files per running job, and for high values of -j (people are doing -j
builds on very large systems these days) that may be significant.

However, I don't know if it's worth it in reality systems.

> As a nice benefit, you get to avoid leaking the resources due to the
> fact that no one calls fclose on those FILE objects, or so it seems.

They are closed in open_tmpfd(), that's why we dup() the file descriptor
first (so when we close the FILE* we don't lose the underlying file).

But you're right, for Windows this may not make sense and we should
simiply use the FILE*: this is what I was referring to by some kind of
portability layer.

> > Sure... but I don't see the problem.
> Maybe there's no problem, I don't know.

OK.  I think it will behave just as I want, but I'm the one who
suggested this behavior so I'm probably biased.  Let me know of you
think of something that doesn't work about it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]