Broadcast server

[Alex Martelli]

<swell at netcourrier.com> wrote:

> Thx Alex,
>   This is exactly what i want to look at . Async will definitely be
> something i will look at . Does it make sense to mix async and threaded
> server ( let say a threaded server accepting max 10 connections and
> dealing with client request asynchronously ). Does it sounds you a good
> design.

I would spawn a worker thread only for specific jobs that cannot be done
asynchronously, and would dispatch work requests to it from the main
thread, and get results back, via instances of Queue.Queue.  One example
might be interfacing with a database which does not directly support any
asynchronous operation: all work on that DB should be done by one
dedicated thread that does nothing else.  I have a whole chapter of the
Nutshell dedicated to multiprocessing (processes and threads), and in
that chapter I devote ample space (relative to the Nutshell's always
tight space constraints;-) to recommending the architectures based on
Queue instances that experience teaches me work best.

 
> Of course i will have a look a twisted that sounds me doing all the job
> ( for sure better that i can do ) .

It's a well-crafted and rich framework -- in particular, it already
wraps on your behalf some cases of the need for an auxiliary thread, as
sketched above.  On the other hand, learning in depth the "bare metal"
on which Twisted's elegant architecture rests is a highly recommended
endeavor: remember Spolsky's "Law of Leaky Abstractions"... ``all
abstractions leak'', and thus, to use abstractions for the best, you'd
better have a solid understanding of the underlying layers (I strongly
believe that having designed microchips makes me a better assembly
language programmer, having programmed in assembly language makes me a
better C programmer, having programmed in C makes me a better Python
programmer...!-).


Alex