Pythonic way of web-programming

[Chuck Swiger]

Neil Schemenauer wrote:
[ ... ]
> For example, we have a web application that interacts with
> FedEx's servers in order to create new shipping labels, track
> packages, etc.  With an event driven system, waiting for a
> response for FedEx would freeze the entire server.  Obviously
> that can be fixed the hooking into the event loop.  It's just a
> matter of programming, right?

Apparently almost anything can be regarded as a matter of programming, 
as "Strauser family release #3" demonstrates (congratulations!)...  :-)

Do your queries against FedEx's system need to be atomic, and in what 
ways?  If you want is to make multiple outstanding transactions against 
a server asyncronously using an event-driven system without blocking, 
can't you have a multithreaded component that generates queries, listens 
until it gets the response, and then adds each completed transaction as 
an event to a single event queue?

The event-loop & the logic of your application doesn't need to block 
simply because there are some outstanding queries which haven't all been 
answered; you'd only block if there aren't any responses available to 
work on.

> Another example: we have an application that does some CPU
> intensive operations.  We have multiple CPUs in our server.  An
> event driven system would not (normally) take full use of the
> processors.  Also, clients who have IO bound requests would be
> blocked by one CPU bound request.

Hmm.  Well, to continue the paradigm I was using above for this example, 
you could pull off as many responses off the event queue as you have 
processors available; each time a processor finishes with one event, it 
then grabs the next event from the queue.

Sure, if the events might be related to each other-- where the system 
might need to update data which is in use (being processed, has some 
dependency, etc), then the system gets more complex.  You might need to 
have mutexes around the event queue or other data structures, use a 
2-phase transaction with explicit commit strategy, scan for and coalese 
related events in the queue to catch updates, dispatch notifications of 
changed data, interrupt & restart existing calculations, whatever.

Anyway, all of those are solutions to complexities resulting from the 
application's needs; if what you're doing doesn't need them, then the 
"one line of customers feeding multiple bank attendants" type of event 
dispatch model should work fine.

> I have nothing against the event driven model.  However, it is
> not the solution to every network server problem.

I certainly agree with your general notion: programming paradigms may be 
well-suited for some tasks and not well-suited for others.  Perhaps it's 
not clear to me what else you had in mind: non-blocking I/O like 
select() or poll()?  What kind of SMP dispatch system are you using now?

Network server architectures tend to be event driven in design because 
most flavors of network IPC are quantized into discrete network packets 
by the lower levels of the system; local IPC via SysV shared memory is a 
notable exception, though.  Event-driven models tend to be used a lot 
for various aspects of system UIs, and some of those systems might also 
display an unfortunate tendency to have a UI that becomes modal or 
single-threaded while processing events like mouse-drags, but the two 
are not the same thing.

-Chuck