One workaround is to run servers under tcpserver: http://pobox.com/~djb/ucspi-tcp.html tcpserver handles a single TCP port with a simple accept() loop. ---Dan P.S. The same bug shows up in (for example) select()+write() if there's more than one process writing to the same open file. Non-blocking I/O is unsatisfactory, as discussed in http://pobox.com/~djb/docs/unixapi.html: Non-blocking I/O (O_NDELAY/O_NONBLOCK) is a feature of an open file. This means that a program cannot set non-blocking I/O for open files shared with other processes, such as stdout; it will screw up other processes that try writing to the same open file at the same time. Resulting reliability problem: If a multiplexing program uses select() to see when it can safely write to a pipe on stdout, and then does the write, it may end up blocking: another process may have filled the pipe just after select() returned. One workaround is to schedule signals to interrupt each I/O operation, but this is unnecessarily difficult to program. Vendors should provide ndelay_read() and ndelay_write() syscalls that do not block. As John Whittaker says: ``It's UNIX. That doesn't necessarily mean it's right.''
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:29:30 PDT