[lkml]   [2002]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 'select' failure or signal should not update timeout

Dan writes:
> Alan Cox wrote:
> > > <>
> > > says that 'select' may modify its timeout argument only "upon
> > > successful completion". However, the Linux kernel sometimes modifies
> > > the timeout argument even when 'select' fails or is interrupted.
> >
> > This is extremely useful behaviour. POSIX is broken here.
> I tried to make use of this behavior back in 2.2 days, I think,
> and ran into trouble. The time remaining wasn't quite right, I seem
> to recall, making this nifty feature less useful. I've since
> given up on it.
> > Fix it in the C library or somewhere it doesn't harm the clueful
> Can you give an example of a clueful package that makes
> use of this feature and would be harmed if select() suddenly
> became posix-compliant?

Daemons that I've written for linux-specific tasks all
use the select timeout in order to wait for an event for a fixed
amount of time, across possible interrupts.

That is to say, they watch the errno after return from select, and if
it was EINTR, then they reenter the select without further ado.
Since the timeout has changed to reflect the time remaining, that's
quite right.

This is typical of deamons doing tcp/ip. I guess one answer would be to
make tcp timeout more configurable.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.029 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site