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

[Tim Murphy]

Some time ago when solving the same problem in a different way we used semaphores on Windows and Linux. Compatibility might make it less interesting but I would suggest pretending that one has semaphores first with some nice little abstraction and then implementing them in the best way the platform has to offer.

We didn't need to support so many platforms but you can see the idea here:
https://bitbucket.org/tnmurphy/raptor/src/fbb2e624d320e5eabc0689105e2f2b80d131ca03/util/talon/sema.h?at=default

Basically each build needs a unique id to be passed around in an environment variable. The top-level make executable's PID should be good enough.  This is used to create the named semaphore.

Platforms without semaphores might use a file and locking or if that doesn't work then they can't implement the feature and you configure it out.

Regards,

Tim

On 24 April 2013 18:14, Frank Heckenbach <address@hidden> wrote:

Eli Zaretskii wrote:

> > I know about this method, but I'm not sure it does what we want here.
> > The number used by this method is not guaranteed to be unique on some
> > versions of Windows.  More importantly, it only works for disk files,
> > I don't know whether it reports a meaningful value for the console
> > device or the null device.
>
> Testing clearly shows it doesn't: GetFileInformationByHandle simply
> fails for handles open on console devices and the null device.  And we
> will be comparing handles for console devices in the majority of use
> cases here.

That's right. Or perhaps pipes (I post-process make's output, to
handle the directories in messages etc. and I suppose the mentioned
Emacs mode does something similar).

> I researched this a bit, and eventually succeeded in finding a way
> that is good enough for both disk files, pipes, and console devices.

Good. (And the null device, I suppose. Though it doesn't really
matter if we write to the null device combined or separate. ;-)

> > > > > >  . STREAM_OK uses fcntl and F_GETFD which both don't exist on Windows.
> > >

> > > Basically we need just any call that succees for a valid file and
> > > fails otherwise.
>

> Found a reasonable solution for that as well.

OK, so only one problem left.

_______________________________________________
Bug-make mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-make

--
You could help some brave and decent people to have access to uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/friends/