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 20:03:44 +0300

> Date: Thu, 18 Apr 2013 21:57:56 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > Date: Thu, 18 Apr 2013 19:09:06 +0200
> > From: Frank Heckenbach <address@hidden>
> > 
> > >  . calculation of combined_output in start_job_command will need to be
> > >    reimplemented for Windows, since the reliance on st_dev and st_ino
> > >    makes assumptions that are false on Windows.
> > 
> > What we need is basically "is_same_file (fd1, fd2)" (which we
> > probably could refactor into a separate function). Eli, can you try:
> > 
> >   test file1 -ef file2
> > 
> > where test is either a standalone utility or a built-in of bash or
> > any other shell. If any of these works, you can see how they do it.
> > Otherwise, a bit of googling turned up this page which has code (in
> > Python, but it seems like a thin layer around the system calls, so
> > it can probably easily be ported to C):
> > 
> > http://timgolden.me.uk/python/win32_how_do_i/see_if_two_files_are_the_same_file.html
> 
> 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.

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

> > > > >  . STREAM_OK uses fcntl and F_GETFD which both don't exist on Windows.
> > > > 
> > > > This is to test if somehow make's stdout or stderr has been closed (not
> > > > just redirected to /dev/null, but closed).
> > > 
> > > Right, got that; but Windows needs a different test for that, as
> > > there's no fcntl.
> > 
> > Basically we need just any call that succees for a valid file and
> > fails otherwise. fstat() might be a good candidate.
> 
> fstat is too heavy on Windows; there are better methods.
> 
> > If that isn't available, maybe even lseek() (as used in
> > FD_NOT_EMPTY) will do if we keep the "|| errno != EBADF" test.
> 
> lseek fails for the console as well, so it's not a good candidate.
> But this problem is not difficult, I just mentioned that the code as
> committed won't compile.
> 
> > Eli, can you do some tests to see if you find something that works
> > reliably?
> 
> Don't worry about that.  My worst problem is lack of time, not lack of
> ideas ;-)

Found a reasonable solution for that as well.



reply via email to

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