On Tue, Jan 6, 2009 at 6:47 PM, Vadim Zhukov <[email protected]> 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.
