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 -- http://mail.python.org/mailman/listinfo/python-list
