Re: Advanced Auto-Dependency Generation and Parallel Execution

[Garrett Cooper]

On Mon, Dec 1, 2008 at 6:51 PM, Garrett Cooper <address@hidden> wrote:
> 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

s/bugs/teammembers/

-Garrett