Re: UDP recvmsg blocks after select(), 2.6 bug?

[Jean-Sebastien Trottier]

Just an outsider's view of someone that has been following this thread:

Could select() have 2 different behaviors depending on wether the
O_NONBLOCK flag is set or not on the socket.

1. If O_NONBLOCK is set, it can immediately return that the socket is
ready to be read (while CRC and possibly other checks are being done in
background). A subsequent call to recvfrom may return EWOULDBLOCK if in
the mean time the data was discarded by the kernel. This is current
behavior.

An application using O_NONBLOCK should be ready to deal with
consequences.

2. In the case where O_NONBLOCK is not set, select() could wait for all
the checks to be done before deciding to return or not. In this case the
meaning would be "there is data ready", NOT "there *might* be data
ready".

This way, there should not be any performance hits for (IMHO) well built
applications that use O_NONBLOCK. And the POSIX standard would not be
broken otherwise and applications that don't use O_NONBLOCK can rely on
actual data being read in recvfrom.

Just my 2 cents...
Sebastien

On Thu, Oct 07, 2004 at 02:36:26PM +0100, Paul Jakma wrote:
> On Thu, 7 Oct 2004, Martijn Sipkema wrote:
> 
> >Any sane application would be written for the POSIX API as 
> >described in the standard, and a sane kernel should IMHO implement 
> >that standard whenever possible.
> 
> NB: I dont disagree with you.
> 
> Just the impression I get is that there is no way to avoid this 
> situation without a serious performance impact, and that the 
> optimisation shouldnt really any affect any healthy app. (any which 
> are really should be setting O_NONBLOCK).
> 
> If you could follow the spec without significantly harming 
> performance, then I'd agree spec should be followed.
> 
> I dont really have anything useful to say other than that, IMHO, a 
> sane app should be using O_NONBLOCK if it really does not want to 
> block, so I shall now quietly back away from this thread.
> 
> regards,
> -- 
> Paul Jakma	paul@xxxxxxxx	paul@xxxxxxxxx	Key ID: 64A2FF6A
> Fortune:
> What this country needs is a good five cent microcomputer.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/