[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Single-threading servers and select()
- From: skaller <skaller@...>
- Date: 23 Jan 2005 21:16:33 +1100
On Sun, 2005-01-23 at 19:59, Chris Pressey wrote:
> I don't doubt coroutines complicate the programming model considerably.
> But I also don't see why coroutines should be necessary for scalability.
They're not: what's necessary is O(1) - O(log n) context
switching. Coroutines provide the possibility -- note,
its just a possibility -- of fast user space context switching.
This seems useful, considering OS switching usually has two
very bad negatives:
(a) its O(n)
(b) the process code is typically written in C
which has a linear stack
Problem (b) rules out any hope of scalability for
C programs on a 32 bit CPU -- there just isn't
enough address space.
> 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.
For some problems processes are great! However threads, and coroutines,
have an advantage -- they can share memory without transmitting
data across a link.
I guess for *real* scalability processes are the only
option -- I mean there is a limit to what a single box
can do, after that distributed concurrent processing
John Skaller, mailto:email@example.com
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net