At Sat, 9 Jun 2007 01:30:49 +0800, Samuel Thibault <[EMAIL PROTECTED]> wrote: > Actually, on the Hurd, a timeout of 0 probably doesn't make sense (since > we at least need to give back cpu to the server). What I'd propose is > the attached patch (not tested), that rounds up the timeout value, and > in the case of 0, uses 1 (so as to give the server an opportunity to > answer). > > Comments?
The problem is quite suble. Here is how SUS describes select: If none of the selected descriptors are ready for the requested operation, the pselect() or select() function shall block until at least one of the requested operations becomes ready, until the timeout occurs, or until interrupted by a signal. The timeout parameter controls how long the pselect() or select() function shall take before timing out. The theory is that we don't trust the server to honor the timeout: it may be malicious and trick the client into waiting forever. However, there are enough ways in which we rely on the server for correct operation that using the Mach timeout mechanism to preempt the server doesn't bring any additional safety. Instead, I think, we should pass the timeout directly to the server and rely on it to honor the timeout according to the specification. Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]