Subject: Re: [Boost-build] [boost] [ATTN: Noel] Re: bjam's use of O_NONBLOCK in execunix.c
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2010-05-13 13:04:12
I apologize for the delay in responding, way too much going on at the
On May 6, 2010, at 9:04 PM, Rene Rivera wrote:
> Taking this to the build list..
> On 5/6/2010 12:29 PM, Dan Gohman wrote:
>> Why does bjam on "unix" platforms set the O_NONBLOCK flag when
>> standard output and error pipes from the child process to the
>> parent process?
>> This was introduced in change r38009:
>> The parent process uses select(2) to block and wait for output from
>> so it doesn't appear to need non-blocking file descriptors.
>> Child processes are unrelated programs, and it seems mistaken to
>> assume that
>> they will want their stdout and stderr to be non-blocking. A
>> project that
>> I'm involved in recently had to add code to handle EAGAIN from a
>> write(2) call
>> by spinning until it succeeds, and it seems to be fairly common
>> It would seem to be better if the parent would just leave the file
>> in blocking mode.
> Noel Belcourt wrote the Unix command handling so I don't have an
> as to why. Noel any comment?
I think you're correct Dan that we should probably leave the pipe file
descriptors alone unless we have a good reason to force them to be non-
blocking. I've tested removing the non-blocking fcntl calls on
Darwin, Linux, and Solaris and didn't see any problems in the build
system responsiveness or throughput for serial or parallel builds so
I'm okay with this change.
Rene, I didn't test the effect on the -px pipes flag as my nightly
tests don't use this feature.
Dan, do you want to commit this change or shall we?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk