Re: Patch for Makefile race against current cvs
От | Tom Lane |
---|---|
Тема | Re: Patch for Makefile race against current cvs |
Дата | |
Msg-id | 398.1005532607@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for Makefile race against current cvs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch for Makefile race against current cvs
Re: Patch for Makefile race against current cvs |
Список | 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
В списке pgsql-patches по дате отправления: