On Tue, 31 Oct 2006 07:33:59 GMT, Bryan Olson <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
