Bug#79358: is select still broken on hurd ?

["Neal H. Walfield" <neal@walfield.org>]

At Sat, 9 Jun 2007 01:30:49 +0800,
Samuel Thibault <samuel.thibault@ens-lyon.org> 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