On Thursday, 13th January 2005, Peter Jeremy wrote: >On Wed, 2005-Jan-12 23:54:38 +1000, Stephen McKay wrote: >>a) Rewrite file descriptor handling in libc_r so it does not set O_NONBLOCK >>on tty file descriptors unless it is in the foreground. I don't know how >>hard this would be, or whether it even applies to -current with its profusion >>of threading libraries. I'll leave this to those who believe in threading. > >In 4.x, threads are totally userland and rely on non-blocking I/O. If >background tty file descriptors block on I/O, the entire process will >block, not just the thread performing I/O. This is a major POLA violation.
Maybe yes, maybe no. The process stops with SIGTTOU. Stopped is stopped. My view is that it's a POLA violation to allow other processes to fiddle with non-blocking mode behind your back. Anyway, this problem goes away if we can have O_NONBLOCK be per file descriptor rather than per file open. Then it doesn't matter if a threaded process changes its own copy of the tty descriptor. Until then, anyone who wants to can protect themselves with my patch. It's working fine for me. :-) >In 5.x and later, both kernel and userland threads exist. I am totally lacking in info on 5.x and 6.x threading. If we can get rid of O_NONBLOCK here (or if it's already gone), then the major problem is solved. And my code to prevent non-blocking being set by background processes can be committed. (Better safe than sorry.) >>b) Add new non-blocking read() and write() call variants and use them in >>the threading library instead of setting O_NONBLOCK. > >See aio_read(2), aio_write(2). These look hard to use. I can't see how they could replace nonblocking reads using O_NONBLOCK. Even if I add kqueue() to the mix I see problems. By the way, I found a note about this from the author of djbdns. He has much the same complaints I have. See http://cr.yp.to/unix/nonblock.html >>c) Make O_NONBLOCK be per file descriptor (like FD_CLOEXEC). Thus, >>descriptors produced from dup() (for example) would have their own O_NONBLOCK >>flag, just as two descriptors from separate open() calls have today. > It might be useful to see what one of the POSIX experts think about this. >FreeBSD, NetBSD, OpenBSD and Linux all explicitly state that dup(2) >copies O_NONBLOCK (though Solaris 10 doesn't). It is reasonably likely >that existing code relies on the documented behaviour and will therefore >break when you move O_NONBLOCK from the file to the file descriptor. You can still have dup() copy the O_NONBLOCK flag. That's probably sensible. But if you did "b = dup(a)" then changed the O_NONBLOCK flag on "b" you wouldn't see that reflected on "a" (unlike now). Even after sleeping on this, I think option c) is the right answer. Stephen. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
