Re: Advanced Auto-Dependency Generation and Parallel Execution

[Garrett Cooper]

On Mon, Dec 1, 2008 at 6:30 AM, Philip Guenther <address@hidden> wrote:
> On Sun, Nov 30, 2008 at 12:17 AM, Josh Davidson <address@hidden> wrote:
>> However, I'm wondering if the use of sed in creating the dependency files
>> could create potential problems under parallel builds (-j).
> ...
>> "Another problem is that two processes cannot both take input from the same
>> device; so to make sure that only one command tries to take input from the
>> terminal at once, make will invalidate the standard input streams of all but
>> one running command. This means that attempting to read from standard input
>> will usually be a fatal error (a `Broken pipe' signal) for most child
>> processes if there are several.
>
> This is referring to attempting to read from the standard input that
> was supplied to make and therefore inherited by default by the
> commands make runs.  If a command closes that and opens some other
> file as stdin, then parallel execution won't have a problem.
>
> Here's an example that _would_ have a problem:
>
> all: foo bar
> foo bar: FORCE
>        @echo "touch address@hidden"; read touch; case $$touch in [yY]*) touch 
> $@;; esac
> FORCE:
>
>
> Philip Guenther

Another issue is ncurses and how it does it's echo'ing (see the
following line from progs/Makefile.in):

transform.h :
        echo "#define PROG_CAPTOINFO \"$(define_captoinfo)\"" >$@
        echo "#define PROG_INFOTOCAP \"$(define_infotocap)\"" >>$@
        echo "#define PROG_RESET     \"$(define_reset)\""     >>$@
        echo "#define PROG_INIT      \"$(define_init)\""      >>$@

Under certain conditions this fails (the bugs who reported the
internal bug didn't have a clearcut means for reproducing the issue).
I haven't posted a fix for this as I don't have a solid means of
reproducing it, but yes, this is an example of real-life race
condition prone code (and it may be a potential bug with either gcc or
gmake *shrugs*).

-Garrett