Re: expanding on luaproc ideas

[John Belmonte <john@...>]

I'm repeating the original post, but there are situations when you
want to design for the ability to scale-- the parallelism may or may
not be available for a given deployment.

Consider a circuit simulator, where coroutines can be nicely employed
to manage complexity.  If the implementation is coded directly to the
coroutine API you obviate taking advantage of SMP or computing
clusters for large circuits.  On the other hand, using luaproc as it
stands, you would hamper the maximum circuit size that could be run on
a single-CPU machine due to the overhead of Lua states relative to
coroutines.


On Fri, Apr 27, 2012 at 11:44 AM, Coda Highland <chighland@gmail.com>
> The main reason that adding coroutines as an abstraction here isn't
> beneficial is because it provides no benefit. While it is true that
> coroutines have less overhead than a second full Lua state, coroutines
> have more overhead than simply writing the algorithm serially.
> Coroutines do not provide parallelism; they do not accomplish
> multiprogramming in any real sense. They can't take advantage of
> additional resources such as additional cores, additional CPUs, or
> additional machines.