On Thu, Nov 01, 2012 at 06:20:50PM +0100, Svante Signell wrote:
> OK, 1ms seems to be a little long. If the time-resolution had been 1us
> it could have simplified the problem a lot.
This is what my select_timeout branches in some hurd repositories is all
about BTW. But with the recent work on pth
On Thu, 2012-11-01 at 18:08 +0100, Samuel Thibault wrote:
> Svante Signell, le Thu 01 Nov 2012 18:04:35 +0100, a écrit :
> I have added 1, just like you tried to in your patch.
>
> to = (timeout->tv_sec * 1000
>
> so it's ms.
OK, 1ms seems to be a little long. If the time-resolution had b
Svante Signell, le Thu 01 Nov 2012 18:04:35 +0100, a écrit :
> On Thu, 2012-11-01 at 17:44 +0100, Samuel Thibault wrote:
> > Svante Signell, le Thu 01 Nov 2012 17:32:53 +0100, a écrit :
> > > --- ../hurdselect_orig.c 2012-10-21 22:55:26.0 +0200
> > > +++ ../hurdselect_orig_timeout.c 2012-
On Thu, 2012-11-01 at 17:44 +0100, Samuel Thibault wrote:
> Svante Signell, le Thu 01 Nov 2012 17:32:53 +0100, a écrit :
> > --- ../hurdselect_orig.c2012-10-21 22:55:26.0 +0200
> > +++ ../hurdselect_orig_timeout.c2012-11-01 12:58:00.0 +0100
> > @@ -84,9 +84,13 @@
> >
> >
Svante Signell, le Thu 01 Nov 2012 17:32:53 +0100, a écrit :
> --- ../hurdselect_orig.c 2012-10-21 22:55:26.0 +0200
> +++ ../hurdselect_orig_timeout.c 2012-11-01 12:58:00.0 +0100
> @@ -84,9 +84,13 @@
>
>to = (timeout->tv_sec * 1000 +
> (timeout->tv_n
Hello,
I'm currently working with an update of hurdselect.c in eglibc, and
found a problem with non-blocking delays of value zero. This problem has
been seen before for vi for select and a workaround hack is currently in
the Debian version of eglibc-2.13. I have also seen this problem with my
new
