lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 23 Jan 2005 16:28:59 +1100
skaller <skaller@users.sourceforge.net> wrote:

> BTW: I would like to add something here. There is
> a web-server based problem which is a higher level
> generalisation of the connection problem:
> maintaining many simultaneous *sessions*.
> 
> Even when HTTP connections are transient, most
> e-commerce systems require a logical connection
> (called a session) to be persistent.
> 
> The issue here is not implementation details or
> performance, but programmability -- you would like
> to write your interaction with the client
> as if you were talking to them .. not as if you
> got locked up in a cupboard between each sentence,
> and had to emerge each time and reconstruct the
> conversation.. :)
> 
> A very high level system was designed to support
> making this transparent. By high level .. I mean
> it required some heavy duty category theory which
> replaced Haskell monads with a new more powerful
> concept (called Arrows -- i.e. this is bleeding
> edge academic research ..)
> 
> So this problem of 'scalability' is not simple,
> and isn't just a 'select vs poll vs kqueue' problem:
> the problem is much more fundamental than that.
>
> I.e. Lua, Felix, Cappriccio, Io, and most other
> such systems that recognize the need for coroutines
> all use different models because we simply don't
> know how to use them due to a lack of theory.

I don't doubt coroutines complicate the programming model considerably. 
But I also don't see why coroutines should be necessary for scalability.

For instance, Erlang doesn't have coroutines, yet YAWS certainly seems
scalable:

  http://www.sics.se/~joe/apachevsyaws.html

The process-oriented approach encouraged by Erlang also means that code
is quite simple compared to the equivalent done with coroutines - a
"middleman" process can handle the session-keeping while a "backroom"
process can seamlessly work within the session, i.e. oblivious to the
fact that the actual TCP/IP connection comes and goes.

-Chris