modern moo
Littlefield, Tyler
I've been considering using MOO for some ideas I had that I wanted
to get going. I've been stopped by a couple of factors.
First, a lot of stuff I want to do is AI related which requires a bit
more speed than MOO is capable of. While we are running on good hardware
now, the fact remains that most of this code is incredibly old and could
be made to run way better. We could also have some more modern features
that would make MOO a more relevant option. Given this, I had a couple
of thoughts/questions.
I'd like to put my time/efforts into a modern moo, written in c++ and
built to be cross platform (windows/linux/osx). I had a couple of ideas
I was curious if people were interested in.
*Lpc supports a kind of atomic function; basically you can run this
function and whatever happens previous gets rolled back if the function
does not work. I'm not quite sure how this works, but it could be
incredibly useful. Perhaps atomic verbs could be used where the verb in
question would take a snapshot of the object before it started and then
revert back to that snapshot if things didn't go as hoped.
*Multi-threading: I'm not really sure how this would work but it could
be really useful to split your code up across cores. For example my
Linode just got upgraded to shiny new processors running 8 cores, but
MOO wouldn't take advantage of this. How would MOO be able to utilize
this? I was thinking that verbs that are executing could be put into an
execution pool and picked up by threads that handled it to run, so
multiple verbs could be executed across multiple cores. Another thought
would be to split connections up on different threads and balance them
out. Tasks could also have this sort of balance, where execution would
be put in a queue and handed off to the thread that could easily handle it.
*The flat-file db is kind of a pain; why not something like mongoDB?
Each object could be stored in the database and read back in as needed.
*I also want to see something better for local editing. Any
thoughts/suggestions as to how this could be done?
*I would also like to extend the MOO language itself, but I have no clue
to begin with the parser.y mess. If people have had experience working
with this, any pointers would be awesome. It would be nice (though not
necessary) to rewrite the grammar in boost::spirit, with karma as the
backend to do the bytecode translations.
*Packages to extend builtins. I'm thinking of things like file utils,
math utilities/etc. The idea is that these would be written and loaded
in at runtime given a list of modules(packages) to load. They would be
basic dynamic libraries (.so/.dll) and could register their builtin
functions with a registry. Is there anything else these packages could
do that would be moderately useful? Perhaps they could register other
services (web/http comes to mind) and expose handlers or events that the
database could utilize. Then all of the heavy lifting is done on the
server side and not in MOO itself.
*VM/string handling improvements. I'm no great master at VMs or how they
work, so any ideas again would be nice. I remember hearing people talk
about the bytecodes being inefficient.
*Any other ideas to make this work better would again be extremely useful.
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
Littlefield, Tyler
Some responses: (apologies for not doing them as inline, but my phone hates me right now)
I never manage to get inline right--It's either me or thunderbird; I like to assume it's thunderbird...
Dynamically loading additional builtins sounds rather useful.
I thought so too--it certainly beats "add this line here, add that line there."
As for threading, it would be really difficult / dangerous if implemented badly. That said, I do have a way it could be safely thrown into the existing server without issue: (borrowing from the concept of c#'s async keyword)
- All tasks run on the primary thread by default.
- There is a builtin that takes a reference to a verb, and executes it on an additional thread (But without any perms)
- The builtin returns an ASYNC var.
- Thread execution continues on both, until the primary verb tries to reference the ASYNC.
- The primary verb is forcibly suspended until the secondary thread finishes
- The ASYNC is replaced with the return value if the secondary thread.
- Primary verb resumes, and uses the newly replaced value.
This method retains the thread safety inherent in LambdaMoo (because secondary threads are unable to change anything), while still allowing complicated and resource consuming operations to be outsourced to additional threads.
That sounds a lot more like futures than it does the c# async keyword, but I could be misunderstanding what/how that really works. Essentially the verb could use async then do something with that var (maybe use wait). At specific code points (so the user can finish up stuff before they wait for the return) the user can just provide a code-point at which to wait for the async. Having something like wait{request, x, y, z}) would also be kind of cool--though we want to be careful here obviously because spawning to many threads could get messy. It would ultimately be up to the programmer/admin, but there would need to be a hard limit somewhere maybe with permission controls. I like that idea, though I really do want to blend it with others. I'm not sure how it could be done so that there wouldn't be a ton of issues; I'd ultimately like to set up some sort of software-locking system on properties at a higher level so that you don't have to acquire a lock at a lower level. Granted this would still incur some overhead on references, but it would be a lot less. In the least though, it would be nice to be able to have specific systems run as a separate thread; perhaps heavy-load verbs such as updates. i'm not sure if that would change the locking issues because you'd have the problem of determining what actually needed locking, but it's a thought.
The idea of 'atomic verbs' would be difficult for two reasons:
- The inability to track which verb has changed things. This could be fixed easily if we didn't use a flatfile, because each db operation could record the taskid that caused it
- More importantly, the idea that if an 'atomic verb' suspended, let another verb reference it's "results", then rolled back. How would this be dealt with? What should the other verb do with this ghostly data. How would it even know?
And preventing other verbs from acting whilst an atomic verb is suspended would counter the point if suspending in the first place.
I'm honestly not sure that an atomic verb -should- be able to suspend itself. It's not like your usual task where you handle a timed set of atomic verbs; something like that would need to be tightly controled. If you wanted to use it say for updating a system or players or something, ultimately you would run your usual updater verb that just runs it's suspend to run as a background task, then that verb would call into another atomic verb. We could have it marked with a "a" flag to signify atomic and it would behave the same as any other verb, with the exception that a return of false (or maybe a call to a builtin function) would determine the state of the verb. so all the atomic stuff is handled behind the scenes and nothing needs to know how it actually works; a return of false would just signify that the verb failed (and you'd know the object was rolled back to the previous state).
-Stephen
--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To post to this group, send email to MOO-...@googlegroups.com.
Visit this group at http://groups.google.com/group/MOO-talk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
