Going Stackless?

Steve smorrey at gmail.com
Tue Feb 27 17:46:06 MST 2007


Thanks for the information on these stackless implementations.
It looks like my idea of spawning a stack object and effectively just
passing it around, may be the right way to go when a function call has
the potential to block.

As to the comments about listening/not listening.  In fact I am
listening, the network server runs only a small handful of threads,
the operations the threads run are heavyweight enough to justify their
own threads IMHO, and the listener portion is event driven and using
select :D

About the language design, I'm doing my own simply to learn how to do it.
I want to know how languages operate.  I want it fast, lightweight and
targeted to my problem domain.  What will probably end up happening is
it'll be slow, bloated, and turn into a kitchen sink language as I
experiment :D

FYI I've read every line of code that makes up Lua,  I've even gone so
far as to step through the entire engine line by line in a debugger.
In fact thats what has me started down this path.  I read it, but I
don't understand some of the design decisions, I want to figure out
why certain things were done the way they were.
I figure there is no better way than to make my very own.

Regards,

On 2/27/07, Levi Pearson <levi at cold.org> wrote:
> Steve <smorrey at gmail.com> writes:
> > Hey there everyone,
> > I've decided to roll my own scripting language from scratch.
>
> Well, I guess I shouldn't be too surprised that you didn't listen to
> my advice, since you didn't seem to listen to it any of the previous
> times I offered it.  But I suppose you have your reasons.
>
> > At present my VM executes fast and fine until it reaches a blocking
> > call at which time the whole works will freeze until it's unlocked
> > (for instance a long iterative loop).
>
> A problem that has plagued MUD programmers, and writers of concurrent
> programs in general (like time-sharing operating systems), for a very
> long time.  There are also a lot of reasonable solutions.  Many, in
> order to keep things deterministic in the face of concurrency, use a
> cooperative concurrency model.  This is also, fortunately, the easiest
> to implement.
>
> In a cooperative system, a task executes until it decides to yield
> control back to the scheduler.  This has the problem you observed that
> if you aren't careful, a task can steal all the computing resources by
> choosing not to yield.  The typical solution to this is to enforce
> some sort of limit, after which a task is simply stopped and given a
> 'timeout' exception.  Means are provided for a task to see how much
> processor time it has left to use before it's stopped so it can yield
> before time runs out.
>
> This works out pretty well, and keeps things fairly deterministic.
> You still have to make sure you yield in safe spots, where you won't
> leave anything in an inconsistent state.  You do have to be pretty
> disciplined in your coding to ensure you yield when appropriate, but
> not as disciplined as you have to be if your task could be preempted
> at any moment.
>
> > One solution I've come up with is to spawn a child VM, pass the child
> > a reference to the parent, pass it a copy of the stack sections it's
> > going to need, run the child in it's own thread, and have the child
> > notify the parent when the process completes.
> >
> > This works ok, but there is a whole lot of overhead and extra code involved.
>
> Indeed.  Probably not a good idea, especially considering your
> scalability goal, unless you confine the size of the thread pool.  You
> will also have to keep in mind proper locking of data structures in
> your scripts.
>
> >
> > I've been reading a lot about language design and one thing that
> > intrigues me is a stackless model.  It appears to be some sort of
> > programming cure-all but I don't really understand what a stackless
> > language involves, or how it is different from my stack model.
>
> "Stackless" in this context is a bit of a misnomer.  What it really
> means is that you are not using the C stack for your stack; instead,
> you have a linked list or some other data structure containing
> activation records.  Now, instead of being limited to one stack, you
> can have as many as you want at the same time.  This is somewhat more
> expensive than doing everything on the C stack, which has nice
> assembly instructions to manipulate it, but far less expensive than
> creating OS threads for everything.
>
> > Anyways for anyone versed in language design, compiler theory etc.
> > What am I missing here?  How exactly does a stackless language work?
> > What are the pitfalls of a stackless language?
>
> Many Scheme interpreters use a 'stackless' virtual machine, since it
> makes the implementation of first-class continuations much easier than
> it would if you were using the C stack.  It isn't the only way to do
> it, though.  I'm currently reading a paper by Kent Dybvig about this:
> http://www.cs.indiana.edu/~dyb/papers/3imp.pdf
>
> Lua, of course, already has coroutines built into the language.
> Scheme has continuations.  Erlang has a lightweight, extremely
> scalable concurrency model that can take advantage of multi-processor
> systems now.  I think you really ought to use someone else's language,
> because language design is a very difficult thing to get right; far
> more difficult than a network server.
>
>                 --Levi
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>



More information about the PLUG mailing list