How to force a thread to stop

[H J van Rooyen]

"Dennis Lee Bieber" <wlfraed at ix.netcom.com> wrote:

| On Fri, 28 Jul 2006 08:27:18 +0200, "H J van Rooyen"
| <mail at microcorp.co.za> declaimed the following in comp.lang.python:
|
| >
| > Dennis - did your OS not have a ticker running?
| >
| That ancient machine, while round-robin, multi-priority,
| pre-emptive, seemed still to only "deliver" signals on deliberate
| blocking calls -- perhaps to prevent potential corruption if the signal
| had been delivered(handled) in the middle of some multi-instruction
| sequence. The OS level would "see" the <ctrl-c>, and set the signal bit
| in the task header -- but without the blocking I/O (typically), the code
| to activate a registered signal handler would not be invoked. Operation
| was something like: submit I/O request, AND(signal bits, signal mask) --
| invoke handler if non-zero, block for I/O return [or return directly for
| asynchronous I/O request]

- Hah! - so it *could* have responded - it just chose not to - so it was pre
emptive - but hey - what is different between modern OS's and what you are
describing? - it seems to me that there is just a lot of extra memory control,
as well as control over who is allowed to do what - in an effort to make things
more stable - and all this stuff just eats cycles and slows you down... (or
alternatively, makes the hardware more complex and expensive...)

But to get back to the OP's problem - basically the thread has to see some sort
of variable change, or receive a message (by examining something to see if there
is a message there) and then kill itself, or the OS must be told to stop giving
control back to the thread in question - which option will leave all the loose
ends in the thread loose...

So its either: "hey mr nice thread please stop" - or "hey Mr OS - kill that
thread ..." - now from the OS viewpoint - if the application implements some
threading itself - it may not even know that the thread exists - OS threads are
known variously as "Tasks" or "Processes" or "Running Programmes" - so using the
big guns on a thread may not be possible without killing the parent too...

So if you want to use the OS to kill the thread - it has to be a formal OS
thread - something started with a call to the OS, and not something that an
application implements by itself - and I am not familiar enough with Python
threading and dummy threading to pretend to know what is "under the hood" - but
I haven't seen an additional process appearing on my Linux box when I start a
thread - so its either something that Python does on its own without
"registering" the new thread with Linux - or I haven't looked closely enough...

So if somebody else can take over here, we might convince the OP that "hey mr
nice thread" is the way to go, even in the case that the "thread" in question is
an OS Process - after all - there has to be inter - task communication in any
case - so the cleanest solution is to build the kill in right from scratch...

Why do I think of COBOL:

read master_file_record at end go to end_routine....

HTH   - Hendrik