MPR#5371: questionable reasoning in job control code

[damiendoligez]

PR transferred from https://caml.inria.fr/mantis/view.php?id=5371
[original reporter: @glondu]

ocamlbuild recently started failing with dash 0.5.7, which is /bin/sh on Debian, when the ocamldep command writes to stderr. This was triggered by a patch that has been reverted in Debian (see [1]).

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642922

However, after looking more closely at what was going on inside dash and ocamlbuild, I believe ocamlbuild is genuinely faulty: in ocamlbuild_executor.ml, around line 205, it assumes that when reading from a file descriptor that has been returned as ready for reading by select returns 0 bytes, the corresponding job is finished, and it then closes the file descriptors and waits for it. I don't understand the reasoning behind this, and this is blatantly wrong with dash 0.5.7: ocamlbuild closes the stderr of the job (in this particular case, ocamldep) while it is still running, and when the jobs writes to its stderr, it gets SIGPIPE-d and reported to its parent (ocamlbuild) as failed.

I think ocamlbuild should not schedule termination of a job based only on reading 0 bytes from its file descriptor. A possible fix could be to install a SIGCHLD handler to schedule finished jobs instead of doing it after reading 0 bytes. Another one (IMHO better) would be to provide non-blocking variants of Unix.close_process* functions (that would not close fds if the process is not dead), and use them in ocamlbuild. Making them actual part of the Unix module would be a valuable addition, too.