Am Dienstag, den 07.02.2006, 18:44 +0100 schrieb Bardur Arantsson:
> skaller wrote:
> > On Mon, 2006-02-06 at 19:34 +0100, Bardur Arantsson wrote:
> > 
> >> However, if you want very high-performance networking
> >> you'd be better off with something closer to the metal, i.e. something
> >> like a libevent wrapper 
> > 
> > Argg no. Libevent isn't a library, it doesn't control invert.
> > It is a monolithic framework. Therefore it is not very useful because
> > your code will no longer be composable. In particular,
> > there is no way to compose two such frameworks, for example
> > you cannot use it with an event driven GUI framework.
> > 
> 
> Note that I said 'high-performance'.
> 
> Point #1: select() and anything based on it (I believe Equeue still is 
> though I haven't looked at it for quite a while) is woefully inadequate 
> for high performance I/O except in very specific circumstances.

Yes, the default Equeue implementation bases simply on select(). It is,
however, possible to develop alternate implementations. Currently, there
are three of them which integrate into the event loops of labltk,
lablgtk1 and lablgtk2. One could, for example, easily add an
implementation for advanced kernel interfaces like epoll. Or one that
sits upon libevent. There is, however, the basic design decision that
all events pass the same queue. This mainly has a certain scheduling
effect (application-driven scheduling), and increases latency if the
queue gets too long, but shows good behaviour under high load.

select() is, as far as I know, only bad if the file descriptors are
linked with many different processes, because all that processes must be
waked up in order to check the descriptors (even if no I/O can happen).
But if you only have Internet sockets, I expect that select() performs
well.

> Point #2: It is not customary for UI applications to require 
> particularly high-performance I/O, thus rendering the non-composability 
> issue moot.

There are many aspects of high performance, for example throughput,
latency, and whether a low or high number of descriptors are watched. UI
applications are often interested in low latency for a moderate number
of descriptors.

I think there is another point why it is a bad idea to distinguish
between, say UI and server applications. Network components should be
shareable between all types of applications. For example, an HTTP
component is useful for both, so why should we develop an extra one for
specific needs of high performance?

Gerd

> I'm _not_ recommending libevent for general use, just if you want high 
> performance with an easily switchable backend implementation.
> 
> Cheers,
> 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------