Re: async networking

[Bardur Arantsson <spam@scientician.net>]

Gerd Stolpmann wrote:
> 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.

Actually, it might be quite interesting to see one based on 
poll()/epoll(), but I suspect it wouldn't matter much compared to all 
the other stuff that's going in the Equeue code. This is just a very 
vague hunch, though.

[--snip--]
> 
> 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.

There are lots of problems with select(). For example, it generally 
requires copying the file descriptor sets from user-space to kernel 
space for every select() invocation, the scanning of active file 
descriptors afterward can be inefficient(*), from OCaml it also causes 
more pressure on the GC through list allocations for result sets, etc. etc.

(*) If your file descriptor set has large "holes" -- which can develop 
if clients have very variable connection lifetimes -- you'll end up 
scanning lots of memory you don't really need to scan. Algorithmically 
it's all still O(n), but the constants can be _very_ different.

> 
>> 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.

Sure. It's just that select() sucks performance-wise for most purposes. 
The alternatives like the OpenBSD kqueue and poll() are usually much better.

> UI applications are often interested in low latency for a moderate number
> of descriptors.

Sure, but not at the level I'm talking. I'm talking about saturating 
high-bandwidth links, ultra-low latency -- though usually not at the 
same time, obviously ;). You know, the kind of stuff you might even 
consider using C/C++ (shudder) for just to avoid GC.

> 
> 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.

Yup. Though all non-blocking I/O has the basic problem of "one event 
loop to rule them all" unless you go with several threads, each running 
their own event loop... At which point you might as well have each of 
those components just using regular blocking I/O and using threads as 
appropriate. Note, I'm not talking about performance characteristics 
here, just design. Also, exception handling and such can be handled much 
more nicely with a threaded design since they don't "invert" the control 
logic the same way non-blocking I/O tends to do.

> For example, an HTTP component is useful for both, so why should we develop an extra one for
> specific needs of high performance?
> 

Sometimes you just need that last bit of performance where a "nice" 
implementation just won't do.

Cheers,

-- 
Bardur Arantsson
<bardurREMOVE@THISimada.sdu.dk>
<bardurREMOVE@THISscientician.net>

[Postmodernism] is more like a three year old throwing his blocks
around the room because he got frustrated with his failed
attempts to stack them higher.
                                Black Parrot @ http://slashdot.org