bug-make
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Wed, 24 Apr 2013 05:56:49 +0300

> From: Paul Smith <address@hidden>
> Cc: Frank Heckenbach <address@hidden>, address@hidden
> Date: Tue, 23 Apr 2013 16:54:33 -0400
> 
> Without knowing what kind of resource Windows can take locks on, we
> can't really know how to help with that.

The only resources that don't need their names passed to sub-Make are
the standard streams.  I will see if locking works on console handles;
if not, I will have to introduce a command-line argument for passing
the name or the handle of a mutex to a sub-Make.

> we can do whatever the equivalent of inheriting an open file
> descriptor is on Windows...

Doesn't help unless it's a file descriptor of one of the 3 standard
streams.  Any other descriptor needs to be passed on the command line,
for the same reasons we have --job-server-fds option.

> > If we really want to make this reasonably portable (and without that,
> > I cannot see how Paul's dream about less ifdef's is going to
> > materialize), this code needs IMO to be refactored to make the
> > algorithm know less about the implementation details.
> 
> Personally I've never had any luck trying to create portable code from
> scratch, at least not unless I'm very familiar with all the platforms
> which is certainly not the case here.
> 
> Once we see the second implementation it will be a lot more obvious what
> needs to be done to make this more portable.

That's one way.  Another one is to discuss the design more thoroughly
before the patches are accepted.  I tried to turn the discussion that
way when the issue was first brought up, but my comments were largely
ignored (if I compare what was suggested then with what was eventually
committed), and most of the discussions were about the details of the
Unix implementation anyway.



reply via email to

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