On Mon, 23 Oct 2000, Linus Torvalds wrote:
> First, let's see what is so nice about "select()" and "poll()". They
> do have one _huge_ advantage, which is why you want to fall back on
> poll() once the RT signal interface stops working. What is that?
>
> Basically, RT signals or any kind of event queue has a major
> fundamental queuing theory problem: if you have events happening
> really quickly, the events pile up, and queuing theory tells you that
> as you start having queueing problems, your latency increases, which
> in turn tends to mean that later events are even more likely to queue
> up, and you end up in a nasty meltdown schenario where your queues get
> longer and longer.
TUX uses asynchron IO exclusively, and we faced this very same problem.
the solution is to queue events *without* allocating additional memory.
This is done by extending the basic 'object' structure (file or socket, or
http_req) with event queue fields: input, output, [etc.]. Then if an event
happens for any object, it's added to the 'output queue' or 'input queue'
of any interested process, without allocating memory. It's simple, fast,
efficient, and scales perfectly. The allocation of all event-related data
structures is done when the object itself is allocated.
[this method assumes a basic object->process relationship, but that is not
a problem.]
this is how TUX is able to handle hundreds of thousands of sockets at once
in a single process, without any 'meltdown' effect. Every queueing and IO
operation within TUX is O(1).
Ingo