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

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Tue, 16 Apr 2013 12:56:21 -0400
> 
> On Tue, 2013-04-16 at 19:20 +0300, Eli Zaretskii wrote:
> > > From: Paul Smith <address@hidden>
> > > Cc: address@hidden, address@hidden, address@hidden
> > > 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.