"Dennis Lee Bieber" <[EMAIL PROTECTED]> wrote: | On Fri, 28 Jul 2006 08:27:18 +0200, "H J van Rooyen" | <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
