On Tue, 2006-02-07 at 18:44 +0100, Bardur Arantsson wrote: 
> 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.

My only interest lies in high performance networking, specifically in a
high connection / low data volume scenario (at this juncture at least).
The optimal solution is some form of iocp with multiple threads (1 per
open socket initiated at startup). I think at some level of high
performance networking the whole file analogy goes out the window.

The multiple serving threads could actually make for an simple api,
actually. A simple function to add a receive callback for a port would
be all you'd need. You could even pass in a buffer to that callback that
a person could respond directly to for socket send, since the same
thread is handling the send requests as well. 

> 
> Point #2: It is not customary for UI applications to require 
> particularly high-performance I/O, thus rendering the non-composability 
> issue moot.
> 
> I'm _not_ recommending libevent for general use, just if you want high 
> performance with an easily switchable backend implementation.
> 
> Cheers,
>