Re: [Caml-list] Re: async networking

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Dienstag, den 07.02.2006, 20:43 +0100 schrieb Bardur Arantsson:
> > 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.

The Equeue core is quite light-weight, there are just some modules on
top of it that make life easier at the user's option. So it would
matter.

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

That depends all very much on the average data case. E.g. if all the
descriptors generate events at the same time, there is nothing bad with
select(). If the typical case is that only very few descriptors "fire"
it has very much overhead.

The poll() interface fixes a number of these issues. Anyway, in practice
it is not much better than select() just because it is also based on
passive iteration. One needs an actively notifying interface to improve
that.

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

Given that data also needs to be processed by the application, it would
be quite interesting whether the choice of the language makes a
difference here. I would guess the time for GC can be kept low in
relation to the costs for context switches, even for the
high-performance case.

And in O'Caml one can prefer to program in a style that reduces the load
on the GC. A much nicer alternative than considering C/C++ too early.

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

Really? From my experience I would say that exception handling is much
easier in the non-blocking case. Exceptions may raise complicated
synchronisation issues in the threaded design.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------