Comments on Building A Game Application Server part 1

1 Comment.

Python’s slowness has nothing to do with the size of its runtime library (and don’t confuse runtime library with the language itself – Lua and Javascript are both as fully-fledged languages as Python, they just don’t come with as many libraries built-in) and everything to do with how its interpreter and garbage collector are just plain slow. Lua and Javascript both have the advantage of varying levels of bytecode compilation, and the fastest Javascript engines will even JIT down to native code.

Also, for a game server, often you want a lean-and-mean runtime library if only due to security concerns, especially if users can run their own custom scripts (as on a MUCK or MUSH). You really don’t want a user script to be able to, say, open a shell or dump files that are owned by the game server process or whatever.

One of the things I liked about Tcl was that it had an easy-to-enable “sandbox” mode which would disable every builtin that can access things outside of the scripting environment itself, and it had an easy mechanism for further restricting other builtins (such disabling for and while, if you wanted to guarantee the halting-ness of a user script – recursion had a stack size limit, of course, and any other iteration was easy to do using foreach) or enabling ones that were needed by user scripts after all.

Of course, any good game scripting language should have the ability to support multiple threads of execution (in the generic “I can pause this task and resume it later” sense, not necessarily meaning that tasks can be preemptively or concurrently scheduled) and the ability to abort those threads based on fine-grained criteria such as memory usage and time taken.

I know Python does have enough support for threading that such things wouldn’t be so hard to implement in the game server, as does Rhino (a Javascript compiler for Java), but I just don’t know enough about Lua and the like to know if they do. I do know that dealing with those issues in the various other Javascript interpreters (namely JavascriptCore and V8) are ridiculously cumbersome, because they don’t have any built-in threading (or even thread-safety) and so you have to be very careful with e.g. running Javascript in one thread and having a monitor thread try to kill a task that’s taking too much of some resource.

-- fluffy 2017-10-10 12:40 UTC