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

Buddy Lucas
2004-10-17T14:17:23Z

On Sun, 17 Oct 2004 15:35:37 +0200, Lars Marowsky-Bree <lmb@suse.de> wrote:
> On 2004-10-16T17:28:24, David Schwartz <davids@webmaster.com> wrote:
>
> > The kernel elects to drop the packet on the call to 'recvmsg'. This is its
> > right -- it can drop a UDP packet at any time. POSIX is careful not to imply
> > that 'select' guarantees future behavior because this is not possible in
> > principle.
>
> I'm sorry, but according to my reading of POSIX and the Austin spec,
> this is exactly what select() returning 'ready to read' implies.
>
> The SuV spec is actually quite detailed about the options here:
>
> A descriptor shall be considered ready for reading when a call
> to an input function with O_NONBLOCK clear would not block,
> whether or not the function would transfer data successfully.
> (The function might return data, an end-of-file indication, or
> an error other than one indicating that it is blocked, and in
> each of these cases the descriptor shall be considered ready for
> reading.)

But it says nowhere that the select()/recvmsg() operation is atomic, right?

Cheers,
Buddy