From: grahn+nntp@snipabacken.se   
      
   I have a few different applications which have to multiplex reading   
   from several UDP sockets, and also doing other things.  Performance   
   is important to me.   
      
   Today I have (A) a plain old select() loop. When an UDP socket is   
   readable, I try to read one datagram from it, process it, and go back   
   to select.   
      
     [David, we can skip the blocking discussion here -- I know from the   
     previous thread that the read may block here, at least on Linux.]   
      
   Fine, but this has a select setup + wakeup + read overhead for every   
   single UDP datagram.  I could use the Linux epoll interface, but that   
   would only optimize the select setup part.   
      
   Another option is (B) nonblocking UDP sockets. Select as before, but   
   instead of reading once, read and process until EAGAIN.  If I have a   
   growing Rx queue on the socket this should be better ... but on the   
   other hand if I'm faster than the UDP sender this means I call   
   recvmsg() twice for each UDP message.   
      
   A third option (C) is a thread for each UDP socket which just blocks   
   in a recvmsg() loop.  But I don't want threads.   
      
   Are there other options than (A), (B), (C)?   
      
   What do people typically do?  Maybe I should read the bind sources;   
   a DNS should have exactly kind of problem.   
      
     I'm beginning to dislike UDP for this reason too -- does anyone   
     agree with me?  With TCP you can wake up and consume a huge chunk of   
     data if you have a huge userspace buffer to read into. With UDP all   
     you get is one datagram. Maybe there should be a variation of   
     recv/readv/etc which lets you provide buffer space for many   
     datagrams (and their source addresses).   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)