Re: [Boost-build] [boost] [ATTN: Noel] Re: bjam's use of O_NONBLOCK in execunix.c

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

Hi Dan,

I apologize for the delay in responding, way too much going on at the  
moment.

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  
>> creating
>> standard output and error pipes from the child process to the  
>> parent process?
>>
>> https://svn.boost.org/trac/boost/browser/trunk/tools/jam/src/execunix.c 
>> #L189
>>
>> This was introduced in change r38009:
>>
>> https://svn.boost.org/trac/boost/changeset/38009

>>
>> The parent process uses select(2) to block and wait for output from  
>> children,
>> 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  
>> practice.
>> It would seem to be better if the parent would just leave the file  
>> descriptors
>> in blocking mode.
>
> Noel Belcourt wrote the Unix command handling so I don't have an  
> answer
> 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?

-- Noel