[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problem (bug?) with file descriptors when doing parallel make (make
From: |
Paul D. Smith |
Subject: |
Re: problem (bug?) with file descriptors when doing parallel make (make -j 2) |
Date: |
Thu, 10 Nov 2005 14:58:43 -0500 |
%% "Fithian, Craig [IT]" <address@hidden> writes:
fc> I am using make 3.79.1. With the following makefiles:
fc> makefile
fc> test:
fc> $(MAKE) -f sub_makefile test 3>&1
fc> sub_makefile
fc> test:
fc> @echo "some text" >&3
fc> the command 'make' works as expected (prints "some text" to the
fc> screen). The command 'make -j' works as well, but the command
fc> 'make -j 2' (or any # > 1) generates the error "/bin/sh: line 1:
fc> 3: Bad file descriptor" and fails. Strangely, it appears that
fc> when the number of processes is restricted, the parallel make is
fc> not opening up the necessary file descriptors when it spawns
fc> processes.
Make doesn't do that: the shell does it. IOW, make invokes a shell and
hands the command script to the shell, and the shell processes it
(including massaging file descriptors).
fc> I do not have make 3.80 but I do not see any comments in the News
fc> that this bug (if it is one) has been addressed between 3.79.1 and
fc> 3.80.
The NEWS file ONLY lists new user-visible features. It doesn't describe
every bug fix.
However, I do see this same behavior in the latest version of GNU make.
fc> Can you confirm whether this is a bug, suggest a workaround where
fc> it works while restricting the number of processes, and/or give an
fc> explanation why the behavior is different between the '-j' and '-j
fc> 2' options.
The "job server" feature in parallel make uses a pipe to communicate
amongst the various make instances. Obviously, the file descriptors
for this pipe (read side and write side) have to be inherited by
sub-make processes.
I think what's happening is when you hardcode the dup of FD3 in your
script, you're stomping on one of the ends of the job server pipe that
the top-level make has created.
I can further confirm this because if you invoke the top-level make with
FD3 already open, then make's job server pipes are created at the next
higher FD (4 and 5) and then everything works:
Fails:
$ make -j 2
make -f sub_makefile test 3>&1
make[1]: Entering directory `/tmp'
/bin/sh: 3: Bad file descriptor
make[1]: *** [test] Error 1
make[1]: Leaving directory `/tmp'
make: *** [test] Error 2
But works:
$ make -j 2 3>&1
make -f sub_makefile test 3>&1
make[1]: Entering directory `/tmp'
some text
make[1]: Leaving directory `/tmp'
You might file a bug about this, but honestly I don't have any idea how
it could be fixed (short of using some totally different technology for
the job server feature).
You just can't duplicate arbitrary file descriptors when invoking
sub-makes like that.
You could choose a high FD, instead, like 5 or 6 or something higher,
when you do your dup, to be more confident that you stay out of the way
of the job server:
makefile:
test: ; $(MAKE) -f sub_makefile test 8>&1
sub_makefile
test: ; @echo "some text" >&8
will also work.
fc> PS: It would be very nice to be able to turn off parallelism by
fc> target (as opposed to for the whole makefile).
"turn off parallelism by target" is something that needs a lot more
definition, but there is already an enhancement request for a similar
feature.
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist