Secure Python

[Paul Boddie]

Diez B. Roggisch wrote:
>

[Multiplayer game servers]

> Now how exactly does linux (or any other resource limiting technique on any
> OS) help here - killing the whole game server surely isn't a desirable
> solution when one player goes berserk, might it be intentionally or not.

A significant issue is the architecture of the server itself. Is a
per-process solution acceptable or must everything happen in the same
process with lots of threads (or microthreads)? Of course, there are
games using lots of microthreads, although I'm not sure whether they
also use lots of processes, too, and it has been asserted that having
lots of operating system threads or processes is just too resource
intensive, but I think it's especially worth considering the nature of
the platform you're using and what it offers.

Presumably, the original idea with UNIX-based systems was that you'd
employ lots of processes in order to serve lots of customers, players,
and so on, and there were companies like Internet service providers
using precisely that one process per customer model in a naive fashion
(until they exceeded the limit on simultaneous process identifiers in
one particular case, I believe). Subsequent work focusing on throwing
lots of threads into a single server-side container and then trying to
isolate them from each other, all whilst running the container on a
UNIX variant - a classic Java architectural pattern - seems like a
curious distraction when one considers the strong portfolio of
appropriate and readily available technologies that are left unused in
the operating system of the deployment environment concerned.

> It is a recurring and pretty much understandable request on c.l.py to be
> able to do so - sometimes it arises in the disguise of killable threads.
> But unfortunately the solution doesn't seem to be as simple as one would
> wish.

And this is where the hot topics collide: people want performant
multitasking with lots of shared state (the global interpreter lock
controversy) together with sandboxing so that the individual threads
can't access most of that shared state (the restricted execution
controversy). But it's like using a trip to meet the neighbours to
justify a mission to the moon: you can visit the neighbours at a much
lower cost with the vehicles you already have. I hear that various
operating systems support better interprocess communication these days,
but then we meet the third hot topic: why won't it work on Windows?
Something has to give.

Paul