help-make
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]