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-07 01:29:07

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?

Yes.  A page fault has occurred, it could be tomorrow before the cache  
is reloaded.

-- Noel