avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Iourovitski, Ilia" <iiourovit...@ydyn.com>
Subject RE: Non Blocking IO for Cornerstone
Date Thu, 29 Nov 2001 18:11:33 GMT
You may want to look at Medusa, select based web server written in
Python which implements Reactor Pattern.

The uml diagram is here:



-----Original Message-----
From: Peter Donald [mailto:peter@apache.org]
Sent: Thursday, November 29, 2001 5:19 AM
To: Avalon Developers List
Subject: Re: Non Blocking IO for Cornerstone

On Thu, 29 Nov 2001 09:25, Berin Loritsch wrote:
> I am almost done with the first iteration of Non-Blocking IO for
> Cornerstone. I will commit it as soon as I can get it to compile :p.
> way anyone who wants to play with it can--although it probably doesn't
> work.

sounds interesting.

> There is one more abstraction to the whole Connection paradigm to
> make Non-Blocking IO effective.  The reason is that the read/write
> mechanisms require the user to know what on earth they are doing.  It
> almost be better to have a higher-level block that only has the
> read/write/close methods available.

the best architecture I know about is to change paradigms completely. 
Currently almost all java based applications follow the single thread
connection model. Each thread reads data from a single thread and the 
operates on it and sends it back. Even non-java applications are mainly 
written like this.

However this is woefully innefficient performance wise - much easier to
code though, much much easier to verify that that code is correct and is

However if you want to go for real network performance it is pretty much
given that you need to change to an event based architecture. What this
is you usually allocate one thread per CPU to do all your processing.

This single thread does a select() on the relevent resources (ie sockets
our case) and receives events like. 

* 7 bytes received for connection 42
* 7 bytes sent on connection 2 (and thus ready to buffer to send again).

I have seen systems that were previously capable of handling 10
go up to handling 130 or so using an architecture similar to this. 

Actually a while back there was some hubub because someone wrote a java 
webserver that behaved like this and it beat the pants off all the major
native webservers (even those with all the fancy kernel hooks). Can't 
remember exact details but I believe the guy was one of the people on
spec for NIO and that he had already written his own non-blocking io API
part of an academic project.

Anyways great for performance but can be hell to write servers using
architecture... its part of what I do for my "fun" stuff ... and lets
say it is not fun .. the best it could be described as is "a good

> However, this is probable best as a JDK
> 1.4 only thing as I would like to take advantage of a pool of
> DirectByteBuffers that further speed up communication. If the
> is done via char arrays, byte arrays, or strings, we might be able to
> provide an abstraction--but the issue remains that we still incur a
> overhead.
> Maybe we can hash it out later....




| "Common sense is the collection of prejudices        |
|  acquired by age 18. " -Albert Einstein              |

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message