killing own process in windows

[Martin P. Hellwig]

On 03/07/10 21:54, News123 wrote:
> Hi Martin.
> Hellwig wrote:
>> On 03/07/10 21:08, News123 wrote:
>>> Hi,
>>>
>>>
>>> How can I kill my own process?
>>>
>>> Some multithreaded programs, that I have are unable to stop when ctrl-C
>>> is pressed.
>>> Some can't be stopped with sys.exit()
>>>
>>> So I'd just like to terminate my own program.
>>>
>>>
>>> Examples of non killable (not killable with CTRL-C) programs:
>>> - A program, that started an XMLRPC server with serve_forever
>>> - a program, that started a multiprocessing.Manager with serve_forever
>>>
>>>
>> If it is just the xml rpc server you want to kill, there might be better
>> ways. For example look at:
>> http://code.google.com/p/dcuktec/source/browse/source/wrapped_xmlrpc_server/rpc.py
>>
>> with perhaps special interest at the comment on lines 172-174.
> I
>
>
>
> Thanks. this looks like a good solution for an XMLRPC server.
> However when playing with different server modules I fall over and over
> again over code, that can't be shutdown nicely.
>
> Currently I'm still struggling with multiprocessing.managers,BaseManager
>
> bye
>
> N

I haven't used the multiprocessing module yet, but generally speaking I 
believe that everything in python that is server-like inherits from 
SocketServer BaseServer. Probably for you to have all servers behave in 
a way you expect, is to override functionality there, for example in:
http://docs.python.org/library/socketserver.html?highlight=baseserver#SocketServer.BaseServer
the function: handle_request

Though from looking at the source the function serve_forever is just an 
while loop over handle request (blocking or no-blocking), so might be a 
better candidate to replace.

But you still might find that some tcp connections remain open, so 
unless you want to go down to the socket level and explicit close the 
socket, there is not much you can do about that.

For the client side, socket timeout is you enemy, I found something 
rather long as default (300 seconds in the xml-rpc client) but yours 
might be different (it is probably a Python defined standard default, 
but I haven't checked that).

Sounds to me like you will be busy reading up on it now :-)

Oh and just a word to prevent over-engineering, if both the server and 
client is written by you, a lot of problems you anticipate will probably 
never occur because that would require a rogue server or client. Unless 
of course you like making rogue server/clients :-)

-- 
mph