[Monetdb-developers] MapiClient asynchronous interface?

Fabian Groffen Fabian.Groffen at cwi.nl
Sat Nov 18 17:55:10 CET 2006


On 18-11-2006 17:31:52 +0100, Johann Borck wrote:
> > The what are the effects of a long running query?  I don't see any
> > advantage here.  You can just pool between sockets with one "main"
> > thread, and try to read every once in a while by checking if there is
> > data available to be read in the (TCP) buffers.  This is, however, with
> > many connections a deadly situation.
> >
> > Since Johann is working with a webserver, it sounds quite weird not to
> > use threads in the first place to me anyway.
> >   
> Well, that's a big discussion :)  but using an event-driven state
> machine with single- or few-threaded servers is not really an uncommon
> thing, and has big advantages, e.g. the avoidance of context-switches.
> Lighttpd is a prominent example, which performs extremely well compared
> to, say, Apache. For really big amounts of concurrent connections the
> one-thread (or even one-process)-per-connection model really is a
> problem. Using epoll (or the new kevent) one can deal with thousands of
> simultaneous connections without problems,  especially without having to
> waste lots of memory (one object/struct vs one thread) and cpu-time
> (context-switches + dealing with locking issues).

Ok, but in this situation, it looks to me as if you would benefit from a
"real" embedded version of MonetDB, where you just talk to a library
instead, omitting all costs of Mapi/TCP and simply stick to method calls.

> When I have some time, I'll very likely give it a try in case of the
> MapiClient. Changing the io-model should not affect transactions, the
> asynchronous version will of course have to follow the same protocol
> that the synchronous version does.  I just thought maybe monetdb
> supports this already, because in the TCP/IP module there are
> asynchronous methods.

Is asynchronous equal to non-blocking IO in your case?  The latter one
should be too hard, I suppose...




More information about the developers-list mailing list