> 4. It would be desirable to have per socket timeouts, but would > require application changes which are unlikely to happen.
Huh? I was just considering writing the patch for this. What application problems would this create? The worst thing I can see is that it would mean that changing the timeout value on a running system wouldn't affect already opened sockets. Even that may be changable by an external utility if I can think of a way to handle the locking in userland. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
