> From: Paul Smith <psm...@gnu.org> > Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de > Date: Tue, 16 Apr 2013 12:56:21 -0400 > > On Tue, 2013-04-16 at 19:20 +0300, Eli Zaretskii wrote: > > > From: Paul Smith <psm...@gnu.org> > > > Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de > > > Date: Tue, 16 Apr 2013 10:44:39 -0400 > > > > > > On Tue, 2013-04-16 at 16:43 +0300, Eli Zaretskii wrote: > > > > > I'm not sure what the semantics of tmpfile() are on Windows. > > > > > > > > The file is automatically deleted when closed. But the documentation > > > > doesn't say what happens if it is open on more than one descriptor, or > > > > what happens if the original descriptor is dup'ed. I will need to > > > > test that, and perhaps provide a work-around. > > > > > > It might be that we have to allow use of a file handle on Windows, > > > rather than a descriptor. > > > > That doesn't matter, really. One can get one from the other on > > Windows. > > Ah interesting. In UNIX you can get _A_ file handle back from a file > descriptor (using fdopen()), but it's not guaranteed to be the SAME file > handle you had originally. That is, if you run: > > FILE* f1 = fopen(...); > int fd = fileno(f1); > FILE* f2 = fdopen(fd, ...); > fclose(f2); > > you don't get back f2 == f1. And although fd will be closed here, I'm > pretty sure not all the resources associated with f1 are freed, which is > a resource leak that will eventually lead to running out of file > handles.
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). 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? 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. > > > The descriptor-based mutex has the very slight advantage over a > > > system-wide mutex in that if a sub-make's output is redirected it now > > > has its own lock domain. > > > > I didn't mean a system-wide mutex, I meant a process-wide mutex. Will > > this be OK? > > I don't think so: especially now that we support full jobserver > capabilities in Windows we can have recursive make invocations all > running jobs in parallel, and we'd want them to synchronize their output > across multiple processes. If we were only concerned about a single > process we really wouldn't need even mutexes since make is > single-threaded. Right. > > E.g., Make sees that both are connected to the same device and > > redirects them to the same file, but then the job redirects stderr to > > a separate file using shell redirection ("2> foo"). Or vice versa. > > Sure... but I don't see the problem. Maybe I've lost the thread. When > the command starts both stdout and stdin are writing to the same > destination. If the command does nothing special then the output will > be a combination of stdout and stderr in the order in which the command > generated them, which is good. If the command script changes one or > both of stdin/stdout, then they won't be cojoined anymore, yes, but > that's what the user asked for...? Maybe there's no problem, I don't know. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make