[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Single-threading servers and select()
- From: Chris Pressey <cpressey@...>
- Date: Sun, 23 Jan 2005 00:59:31 -0800
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