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

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.