[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c
From: |
Svante Signell |
Subject: |
Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems |
Date: |
Thu, 01 Nov 2012 18:04:35 +0100 |
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.000000000 +0200
> > +++ ../hurdselect_orig_timeout.c 2012-11-01 12:58:00.000000000 +0100
> > @@ -84,9 +84,13 @@
> >
> > to = (timeout->tv_sec * 1000 +
> > (timeout->tv_nsec + 999999) / 1000000);
> > - if (strcmp(program_invocation_short_name, "vi") &&
> > strcmp(program_invocation_short_name, "vim") &&
> > strcmp(program_invocation_short_name, "vimdiff") && !to)
> > - to = 1;
> > }
> > + /* XXX: A timeout of 0 returns immediately, even if no file
> > + descriptors are ready. This is correct according to
> > + POSIX.1-2001. As many programs rely on file descriptors being
> > + ready for a timeout of zero use 1 msec as the minimum delay */
> > + if (to == 0)
> > + to = 1;
>
> Nack. We've already tried that in the past, and and using even just 1
> makes some applications sluggish like hell. See the archive list for
> the current work on actually fixing the issue properly, i.e. adding a
> file server interface for probing.
Which applications have problems, I would like to verify that. For vim
you have added 1us (or is it 1ms?) as a workaround. The vim the code at
hand seems to be: select(0, NULL, NULL, NULL, &tv) in os_unix.c, i.e. a
pure timeout.
Where in the archives to find the correct implementation ideas, both
bug-hurd and debian-hurd has a long history?