From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Klaus Naumann <knaumann(at)gmx-ag(dot)de>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Patch for Makefile race against current cvs |
Date: | 2001-11-12 02:36:47 |
Message-ID: | 398.1005532607@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
I wrote:
> Also, I'm still feeling that we are missing something fundamental about
> parallel make. Surely there's got to be *some* interlock in make that
> prevents multiple subjobs from executing the same rule in parallel.
Sigh, I guess my expectations are too high. Some digging around in
gmake 3.79.1 shows that the submakes coordinate only to the extent
of limiting the *number* of simultaneous child processes, not to the
extent of determining what the children are doing.
I don't think that there is any really bulletproof way to invoke bison
under this sort of scenario: if there are multiple submakes executing
the same build rule then it's entirely likely that we'll see things like
one child installing a y.tab.h file that's been truncated and only
partially rewritten by another child. Yes, the second child will
eventually make it good, but that's little comfort if the first child
launches compiles that fail meanwhile.
But we could provide some security for multiple children of a single
make by changing the rules to be like
$(srcdir)/parse.h: gram.y
ifdef YACC
$(YACC) -d $(YFLAGS) $<
mv y.tab.h $(srcdir)/parse.h
mv y.tab.c $(srcdir)/gram.c
else
@$(missing) bison $< $@
endif
$(srcdir)/gram.c: $(srcdir)/parse.h
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-11-12 03:06:49 | Re: Triggered Data Change check |
Previous Message | Bruce Momjian | 2001-11-12 01:49:57 | Re: [ODBC] MD5 support for ODBC |