How to kill a SocketServer?

[Josiah Carlson]

>>That is very interesting.
>>
>>After doing some research into heavily multi-threaded servers in Python 
>>a few years back, I discovered that for raw throughput, a properly 
>>written async server could do far better than a threaded one.
>>
>>If your request processing takes the most time, you may consider a 
>>communication thread and a processing thread.
>>
>>If your processing thread does a lot of waiting on a database or 
>>something else, it may make sense to have one communication thread, and 
>>a handful of database query threads.
>>
>>What part of a request takes up the most time?
> 
> 
> I wonder if you're making it more complicated than necessary.
> 
> The application uses a lot of CPU as it handles multiple
> concurrent client connections.  That makes a pretty clear
> case for some kind of parallel thread architecture, not
> only to dispatch inputs promptly but also to take advantage
> of commonly available SMP hardware.  As you acknowledge

Just because it handles multiple concurrent client connections, doesn't 
mean it is CPU bound.  Also, 'threading' in Python is not the same as 
'threading' in C or other languages.  I've got an SMP machine, and I've 
used threads in Python, and no matter what you do, it doesn't use the 
entirety of both processors (I've said as much in another discussion 
thread).  I don't know the case in other operating systems, but I would 
imagine you get the same thing, likely the result of the Python GIL.

One should also be aware that Python threads take up a nontrivial amount 
of processor to swap context, so now you're looking at a situation where 
many threads may not be as helpful as you (or even the original poster) 
expects.

Now, stackless with microthreads pretty much solve the "threads are 
slow" problem, but thinking without threads will work on all Python 
installations.


> above, the details of that architecture depend a lot on
> what exactly they're doing - how many connections over
> time, the nature of the request processing, etc.  But at

I agree, which is why I asked "what part of a request takes the most 
time".  Since the original poster hasn't replied yet, I expect he's 
figured out what needs to be done in his situation.


> any rate, now they have a thread waiting in accept, and they
> need to shake it loose.  My answer is `define a shutdown
> request as part of the service protocol', but maybe you
> would have a better idea.

Yeah, I would go asynchronous with a timeout.

while running:
     asyncore.poll(1)
sys.exit(0)

  - Josiah