On Tue, Jan 6, 2009 at 6:47 PM, Vadim Zhukov <persg...@gmail.com> wrote:
> Recently I start running (too) often in GMake's "write error" problem. It
> was reported some times ago here with no result. And after some more
> digging I found that commit in DragonFlyBSD:
>
> http://www.mail-archive.com/commits%40crater.dragonflybsd.org/msg02534.html
>
>> Log:
>> Do not set O_NONBLOCK on a threaded program's descriptors any more.
>> Instead, use the new system calls to directly issue non-blocking I/O.
>> Additionally, force blocking I/O for debug output.
>>
>> This partly solves the problem of programs such as bmake or gmake
>> fork/exec'd children which happen to be threaded.  The children would
>> set O_NONBLOCK on e.g. stdin, stdout, and stderr, resulting in
>> unexpected operation if the unrelated parent program tries to issue a
>> read or write.
>>
>> Solves: gmake 'write error' problem
>
> Can anyone expirinced comment this, please?

We don't have whatever these new syscalls are and are unlikely to
adopt them, so I don't think the fix is particularly relevant to
openbsd.  But yeah, faking threads in userland causes trouble.  If we
replace the thread library with a better one, then the problem goes
away.  Maybe.

Let me qualify that.  The reason for the maybe is that there can be
many reasons for a program to set stdout to non-blocking.  It may not
always be the result of pthread fiddling.  So gmake is still wrong.
If its behavior depends on whether a fd is set nonblocking in a child,
that's a problem.  Just a problem that occurs less frequently without
threads it seems.

Reply via email to