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: Frank Heckenbach
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Thu, 25 Apr 2013 05:14:41 +0200

Eli Zaretskii wrote:

> > Date: Thu, 25 Apr 2013 02:16:33 +0200
> > Cc: address@hidden, address@hidden
> > From: Frank Heckenbach <address@hidden>
> > 
> > > > I can't follow you here. On POSIX, we don't need to pass a fd
> > > > because it's always stdout/stderr. Or do mean something else?
> > > 
> > > I meant the file descriptor passed to fcntl to put a lock on it.  The
> > > value of that descriptor is stored in sync_handle, whose type is
> > > 'int'.
> > 
> > So you want to overload sync_handle to contain an fd on POSIX and a
> > pointer on Windows?
> 
> I don't see it as an overloading.  'sync_handle' is already opaque,
> even its name says so.

Alright, in this case I'd suggest renaming it to sync_fd on the
POSIX side.

> It just so happens that on Unix it is actually
> a file descriptor.  And it just so happens that on Windows it will be
> a handle to a mutex.
> 
> > I'm not sure I'd like this. Since it's used in separate code
> > branches (ifdef'd or perhaps in different source files in compat)
> > anyway, why not define separate variables of the appropriate types
> > (preferably with different names, to reduce confusion)?
> 
> I don't see any confusion (how probable is it that someone who is
> interested in Unix will ever look at the details of the Windows
> implementation, and vice versa?).

I often grep through sources in order to quickly find all places a
declaration is used.

> And we never do that in Make, we
> generally try to use the same variables.  If nothing else, it keeps
> the number of ifdef's down.

My suggestion was under the assumption that we use different
declarations because of different types anyway -- which I still
recommend, though Paul might have to decide this one.

If I understand it correctly, roughly we'd have now:

intptr_t sync_handle;

[...]
#ifdef POSIX
sync_handle = (intptr_t) fileno (stdout);
#else
sync_handle = (intptr_t) get_mutex_handle (...);
#endif
[...]

#ifdef POSIX
fcntl ((int) sync_handle, ...);
#else
lock_mutex ((mutex *) sync_handle);
#endif

I.e., everything about it is separate, apart from the declaration,
and the latter uses a type that isn't quite right for either one.
Though I generally like reducing the number of ifdefs, in this case
it seems more consistent to split the declaration, so it's clear
that these are really two different things. As a side benefit, if in
the future someone tried to use it in common code, they would get
compile-time errors on the other platform, rather than silently
producing wrong code (like applying some fd operation to a mutex
handle).

> Thanks.  I think you need two spaces between sentences (that's GNU
> Coding Standards' requirement), and command lines people type should
> be in @kbd, not @code.  Also, "e.g." needs either a comma or a @:
> after it, to signal to TeX it's not an end of a sentence.

Changed.
--- doc/make.texi.orig  2013-04-24 16:30:05.000000000 +0200
+++ doc/make.texi       2013-04-25 02:08:58.000000000 +0200
@@ -8639,6 +8639,17 @@
 complex parallel build in the background and checking its output
 afterwards.
 
+Note that with this option, each job's output is redirected to a
+temporary file first.  Some commands can behave differently depending
+on the type of their standard output or standard error.  E.g.,
address@hidden --color=tty} might display a colored directory listing when
+standard output is connected to a terminal.  When using this option,
+colors would be disabled because the output of the command goes to a
+file.  Note, however, that it is generally best to avoid such
+commands in makefiles, independent of this option, since the
+different behavior would also be triggered when users redirect the
+whole output of @code{make}, e.g.@: to a log file.
+
 @item -q
 @cindex @code{-q}
 @itemx --question

reply via email to

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