It's different than LambdaMOO because it's transactional (or will be). MOO had a global interpreter lock, was single threaded, and each user got a tick based time slice, so there was not really the possibility for state conflict, and there was concurrency but no real parallelism.
At its peak under heavy load on the machines we had back in the 90s, there was some really bad lag as we all waited in turn to f'ck up the world together.
In my system each task (command) gets a separate thread (well, tokio async thread, so not always a physical OS thread), which is its own fully snapshot isolated DB transaction. State is isolated MVCC style (eventually including all I/O) until commit. If the commit is not successful because of conflict the transaction is rolled back and retried , and the user is none-the-wiser.
It's all experimental of course, but I've spent the last ... some time ... working in and studying database tech, so I'm confident I can eventually make it scale. Right now it's just hoisted over RocksDB as a shim but I'm ... building my own thing on the side which will eventually perform/scale much better for the heavily concurrent multiple-writers scenario.
There's still VM opcode based ticks, as in MOO, and limits on them, but that's more of a resource control / time management system to prevent infinite loops and resource abuse and so on.
Fascinating, thanks for the explanation! Makes me wonder if anyone’s tried building a MOO in Erlang/Elixir or another actor-based system. (Though I’ve probably misunderstood how they’d help with the problem.)
If there's a commonly used (or uncommonly) runtime or language out there, someone has attempted to write a MOO in it. At least I have.
Finishing it, and getting other people to use it... that's another story. I've started building probably a half dozen or more systems over the last 25 years. Some have gotten further along than others, but none ever completed. And yeah, I played with Erlang for it at one point :-)
That's why I just threw my hands up in the air and said "F* it! I'll just make it fully LambdaMOO compatible." Because believe it or not there's still people using the LambdaMOO server (and "Stunt" and things like that) and various cores on it. I can hopefully get their interest; but also it gives you a suite of (really weird, aged, and sometimes questionable...) code to test against, and something to compare to for compliance.
The other thing is it makes sense to build such a system in a "systems" PL like Rust or C++, because it is actually a virtual machine, language runtime, database, has a garbage collector, etc. If you end up caring about performance (might not need to, to start), getting closer to the metal makes sense.
Ooh, all very interesting. I tried a simple experiment about 25 years back with a really, really lightweight green-threads library that I thought might work but I never really understood the synchronisation elements well enough.
I really think the world is kind of ready for a LambdaMOO/JHM system again so I will try to come back to play with it and I wish you well in the meantime!
Thanks. The core problem with making something like LambdaMOO multi-threaded is that once you introduce real parallelism you just end up with the potential for race conditions and deadlock. So you need some kind of isolation to make it work. And given that MOO is basically a ... database... it makes sense to crib from those notes.
These days, I'm not as huge of fan of the OO model MOO embraced. At least not in its pure form. While I'm implementing LambdaMOO slavishly compatible, it's more just to keep myself disciplined. I hope to go beyond it.
The 'fantasy' system I'd construct would be look more like a shared Prolog system than a shared Smalltalk/Self system. It'd be constructed around relations & first order logic. Relational but not crappy like SQL. You can build LambdaMOO on top of such a system, but not really the other way around. I just haven't mentally figured out what a sensible multiuser permissions model looks like in that scenario.
Have you thought about using Logtalk to implement this? The idea (or the parts I think I understood) is very interesting and out of systems environments I saw I think only Logtalk and Mozart/Oz offer features that could help in implementing it. Looking at your other posts, though, it looks like you're more interested in coding the entire system yourself instead of re-purposing something that already exists. :)
At its peak under heavy load on the machines we had back in the 90s, there was some really bad lag as we all waited in turn to f'ck up the world together.
In my system each task (command) gets a separate thread (well, tokio async thread, so not always a physical OS thread), which is its own fully snapshot isolated DB transaction. State is isolated MVCC style (eventually including all I/O) until commit. If the commit is not successful because of conflict the transaction is rolled back and retried , and the user is none-the-wiser.
It's all experimental of course, but I've spent the last ... some time ... working in and studying database tech, so I'm confident I can eventually make it scale. Right now it's just hoisted over RocksDB as a shim but I'm ... building my own thing on the side which will eventually perform/scale much better for the heavily concurrent multiple-writers scenario.
There's still VM opcode based ticks, as in MOO, and limits on them, but that's more of a resource control / time management system to prevent infinite loops and resource abuse and so on.