On Thu, Jul 26, 2001 at 02:56:08PM +0300, Maxim Sobolev wrote:
> I am not sure that the error is what we want to get in this situation.
> Perhaps more *compatible* solution would be wait indefinitely if timeout
> is too large.
I guess this could cause problems for programs that use select to
time stuff accurately?
> Interesting, but this isn't really relevant to my question. I want to
> know why the program in question behaves difefrently when linked with
> and without -pthead flag (bug in libc_r?). Also [EINVAL] is not what
> I'm seeing here, because as you can easily check in my test case
> tv.tv_sec == 4294976, which is less that 1000000000 - upper limit of
> our select(2) implementation depicted in PR 18909.
I think I've found out what is wrong. All timing with the pthreads
library is actually implimented using poll, which takes a timeout
as an int in ms. The timeout you begin with is 2^32-1 as an unsigned
int and gets converted to a timeval and then a timespec and then
back to -1 as an int. Netgative timeouts are converted to zero and
so the code ends up spinning.
I guess what the code should do is set a non-zero timeout if this
sort of problem crops up. I think it will just end up trying the
timeout again when the short timer expires.
Try the patch below. I chose 31 seconds as the timeout 'cos 31
seconds will always be representable in ms in an int.
David.
--- /tmp/dwmalone/uthread_kern.c Fri Jul 27 14:44:52 2001
+++ uthread/uthread_kern.c Fri Jul 27 14:49:10 2001
@@ -699,6 +699,9 @@
* Calculate the time left for the next thread to
* timeout:
*/
+ if (pthread->wakeup_time.tv_sec - ts.tv_sec > 31)
+ timeout_ms = 31 * 1000;
+ else
timeout_ms = ((pthread->wakeup_time.tv_sec - ts.tv_sec) *
1000) + ((pthread->wakeup_time.tv_nsec - ts.tv_nsec) /
1000000);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
