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