bug-hurd
[Top][All Lists]
Advanced

[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?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]