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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make