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

[Roland Kuhn]

Hi Mark!

On Oct 16, 2004, at 8:25 AM, Mark Mielke wrote:

> On Fri, Oct 15, 2004 at 09:58:38PM -0700, David Schwartz wrote:
> > > You're thinking too fast, and skipping the most important point here:
> > >     1) packet was dropped earlier (or was never sent)
> > >          - if select() is issued, it blocks
> > >          - if recvmesg() is issued, it blocks
> > >     2) packet was received, but is corrupt
> > >          - if select() is issued, it does not block
> > >          - if recvmesg() is issued, it blocks
> > > See the problem?
> > I'm talking about the case where it is dropped after the 'select' hit 
> > but
> > before the call to 'recvmsg'. In that case, the select does not block 
> > but
> > the recvmsg does.
>
> You are talking about the make believe case that only exists due to
> the *current* implementation of Linux UDP packet reading. It doesn't
> have to exist. It exists only behaviour nobody saw fit to implement it
> with semantics that were reliable, because the implentors didn't 
> foresee
> blocking file descriptors being used. It's an implementation oversight.
Well, I haven't read the source to see what would be necessary to 
create this behaviour, but David was talking about the situation where 
the UDP packet is dropped because of memory pressure. This event cannot 
possibly be foretold by select()...

Ciao,
					Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching
Telefon 089/289-12592; Telefax 089/289-12570
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.

Attachment: PGP.sig
Description: This is a digitally signed message part