Event driven server that wastes CPU when threaded doesn't

[Jean-Paul Calderone]

On Tue, 31 Oct 2006 07:33:59 GMT, Bryan Olson <fakeaddress at nowhere.org> wrote:
>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.

Much of it is quite well informed.

>
>> 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.

This is not the case.  However, much event-driven code is written
this way anyway, intentionally, for clarity.  If you _want_ opaque
code, or for some reason think it is not opaque to write code in this
manner, then there you can use a library which supports this.

>
>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.

As it must be, because you have changed the atomicity of an operation.
Transparently propagating this up a call stack leads to bugs which are
similar to those found in a system based on pre-emptive multithreading.

>
>[...]
>> 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.
>

Multithreading is _someone's_ friend.  Probably not the OP's, whose
original post made it sound very strongly like he just needed network
concurrency, which is a perfectly fine use-case for event-driven style
rather than pre-emptive threading.

Jean-Paul