Neal H. Walfield, le Sat 09 Jun 2007 00:29:38 +0200, a écrit :
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.
Or it may be buggued and hung.
However, there are enough ways in which we rely on the server for
Neal H. Walfield, le Sun 10 Jun 2007 15:30:15 +0200, a écrit :
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.
Mmm, maybe, but is it really the way we
At Sun, 10 Jun 2007 12:15:20 +0200,
Samuel Thibault [EMAIL PROTECTED] wrote:
Neal H. Walfield, le Sat 09 Jun 2007 00:29:38 +0200, a écrit :
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.
Or it may be
Hi,
(summary for the recall)
things like select(1,[0],[],[],[0,0..999]) always return 0 immediately
About the 0..999 range, it's just that the timeout value is divided (and
rounded down) by 1000.
Now, we have a pile of issues: in gnumach's ipc_mqueue_receive(), if
time_out is zero, the
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
5 matches
Mail list logo
