On Mon, Jun 04, 2012 at 02:44:19PM +0200, Joachim Nilsson <troglo...@gmail.com>
wrote:
> On Mon, Jun 4, 2012 at 2:29 PM, Marc Lehmann <schm...@schmorp.de> wrote:
> > On Mon, Jun 04, 2012 at 08:41:38AM +0800, 钱晓明 <mailtoanta...@163.com> 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_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
