Event driven server that wastes CPU when threaded doesn't

Bryan Olson fakeaddress at nowhere.org
Tue Oct 31 08:33:59 CET 2006

Snor wrote:
> I'm attempting to create a lobby & game server for a multiplayer game,
> and have hit a problem early on with the server design. I am stuck
> between using a threaded server, and using an event driven server. I've
> been told time and time again that I should use an event driven server
> design (that is, use twisted).

I didn't hear the specifics of how you got that advice, so I
can't comment specifically. I will say that I've have heard a
lot of advice against threads that struck me as simply naive.

> There is a lot of interaction between the clients and they would often
> need to write to the same list of values, which of course becomes a
> problem with a threaded server - so event driven solves that problem,
> and I assumed it would solve all my problems. [...]

The purely event-driven style solves some problems, but creates
others. You're forced to structure your code around the blocking
behavior, and that's not the structure anyone would choose for
clarity or maintainability.

Suppose we're enhancing an event-driven system, and decide to
relocate some datum from a variable to the database. Suppose in
one or more places, accessing the data happens in a call chain
several function down from the event loop. We can't just change
the function that accesses the data because a synchronous
database call could block and stop event processing. Every
interface on the call chain is broken.

> I will want the server to support as many users as is possible on any
> given machine - and so wasted CPU cycles is something I am trying to
> avoid.

Python is a great scripting language, but squeezing out machine
performance is not where scripting languages shine. That said, you
might start in Python, to see if your system is successful and the
performance of your server really is a limiting factor.

> Is the only solution to use a threaded server to let my clients make
> their requests and receive a response in the fastest possible time?

Maybe. Probably not. It's all good -- multi-threading is your friend.


More information about the Python-list mailing list