multi-ev_loop on UDP socket

Marc Lehmann schmorp at
Mon Jun 4 15:40:19 CEST 2012

On Mon, Jun 04, 2012 at 02:44:19PM +0200, Joachim Nilsson <troglobit at> wrote:
> On Mon, Jun 4, 2012 at 2:29 PM, Marc Lehmann <schmorp at> wrote:
> > On Mon, Jun 04, 2012 at 08:41:38AM +0800, 钱晓明 <mailtoantares at> wrote:
> >> If there are more than one event loop on same udp socket, and each of
> >> them in different thread, datagrams will be processed by all threads
> >> concurrently? For example, one thread is processing udp message while
> >> new message arrived, another thread would process this one immedately?
> > Well, with luck, yes. Without luck, all your threads will try to process
> > the same packet, but only one will succeed, and everything is slow and
> > awkward :)
> With luck?  Is it even possible to achieve something like that
> without having one callback for the socket (per socket), sort
> out each packet and then delegate further to other sockets
> and callbacks?

Well, if you have multiple select's (or e.g. epoll_wait's) on the same fd
and it becomes ready, then it depends on the OS, the backend mechanism
and the timing. Most event mechanisms would signal readiness to all
threads/processes selecting the fd at the moment, until the packet is read.

If the processing of the udp packet takes comparatively long, then you will
have few threads selecting on the fd (in the best case only one on average),
because the others are busy processing something else.

For a server that has to process a lot of packets/s, this might actually
be beneficial, but it's really hard to tell - you have lower overhead for
communicating between threads, but more overhead if multiple threads
select at the same time, and you can't influence this well.

Many preforked servers use exactly this model (apache for example), and
apache also comes with a variety of os-specific hacks that try to avoid
bad performance because evry request wakes up every server process (by
e.g. using fcntl locking to serialise and so on - some operating systems
really need this, some just work well, some work well only for accept()
etc. etc.).

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list