[cmrdporcupine]

It's multithreaded with multiversion concurrency control over shared state. Each command invocation is a new thread, in a new transaction, and the database attempts to resolve any shared state conflicts at commit time.

There's still ticks and time limits, but they're there to impose time / resource limits, not used to control access to shared state.

Tick-based time-slicing to the database is one reason why LambdaMOO (and its offshoots like toaststunt, etc.) has intrinsic scalability limits. (In the 90s, LambdaMOO-the-actual-MOO used to lag like a son of a bitch under load...)

(This is not to say the actual impl of MVCC I have right now is ideal. It's a work in progress. I just defer to RocksDB's conflict resolution, and it is built on assumptions of "single writer, multiple readers" at its foundation, which isn't ideal for what I'm doing... )

[miki123211]

Can this transactional model be made to handle in-transaction I/O?

I've seen MOOs that had verbs for performing HTTP requests, through shelling out to curl IIRC. If you have a verb that reads a value, sends it out and updates it based on the response, what do you do if the value changes in the meantime? When is the transaction committed exactly?

[cmrdporcupine]

I won't be providing outbound HTTP (or inbound) requests via MOO code. The only I/O is what is provided through the Session interface which is, yes, transactional; all I/O "effects" are buffered and committed or reverted after the same at the DB level. Inbound HTTP is provided at the Rust layer in front of a standardized RPC interface over 0MQ and goes through the same set of transactional semantics as all other commands:

The transaction gets committed at the end of command execution, and then all the I/O that "occurred" in the narrative log gets output to its destinations. If a serialization conflict occurred, the output buffers (and all other mutations) are discarded, and everything retried, again. (In theory. Right now it just rolls back and barfs, because I have not finished this layer yet :-) )

Where this falls over is with MOO's synchronous "read" builtin, which is used in places for e.g. password changes or prompts. This is something I have not tackled yet, but will probably just have to deprecate, and will be one of the only things breaking compatibility with existing cores.

Alternatively I could or might provide a transaction mode which is "softer" for tasks that need that kind of dependent input.

It will require some thought. But on the whole MOO's model is similar to a database: In a DB it's query in, commit, see results; in my system in it's command parse, execute verb, commit, flush I/O results out.

[smirya0]

read() would be a killer feature for adoption. There's a ton of MOOs that make use of this in-verb, for menus or other things.

For example:

color = player:choose("Pick a color", {"Red", "Orange", ...});

[cmrdporcupine]

Yeah it's tricky, but TBH I've never been comfortable with this way of interacting with the user on a MOO. It breaks the standard method of interaction there, which is command-verb based. To have the player pick from a menu... don't create a prompt... create a menu "thing" in the world and have a "choose" verb on it and ask them to interact with it.

"read" def presents a problem for the transactional model. So like I said I have basically 3 choices: not implement it, or loosen the transactional constraints for verbs that require it. the latter would be something like: as a user I accept that this could blow up at commit and require me to enter the prompt again ("I'm sorry, something went wrong and I'll need you to enter that again."), or treat it like suspend() which actually creates a new transaction (commits and then creates a new one)