killing thread ?
Irmen de Jong
irmen at NOSPAM-REMOVETHIS-xs4all.nl
Fri Jan 24 18:35:22 CET 2003
Paul Rubin wrote:
> Skip Montanaro <skip at pobox.com> writes:
>> Paul> Pick one of the unused ones from the above (probably from the
>> Paul> 33-61 range).
>>My MacOSX system only goes up as high as 31 (SIGUSR2). Is calling kill(47)
>>going to be defined?
> On the Mac, you'd use SIGUSR2. I don't see what's so hard to
> understand about this. Threads are an OS-specific feature to begin
> with. You have to expect the internal interface to them to also
> not necessarily be the same for every OS.
This discussion makes me think back with pleasure at the way threads
were implemented in AmigaDOS... Every process was essentially a thread.
(AmigaDOS didn't have memory protection/processes). The threads could
listen on a flexible set of self-defined "message ports", and various
Thread signaling took place by sending a message to a message port
(zero-copy by the way), or signaling the thread (for instance, CTRL-C
was a special signal). Thread woke up because AmigaDOS signalled
it "hey wake up, these-and-these message ports have a message for you".
Asynchronous I/O was done using the exact same message port mechanism.
I don't remember if there was a way to kill a thread. There probably
was. With severe side-effects ofcourse (non-freed resources).
If there wasn't, you could ofcourse hack the Exec task list and
manually remove the process node ;-)
Back when I did AmigaPython, I never tried to build AmigaDOS threading
support into the interpreter. Could it have been hard to do so?
Forget my rambling ;-)
More information about the Python-list