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.


<offtopic>

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 
signals.
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?

</offtopic>

Forget my rambling ;-)
Irmen.





More information about the Python-list mailing list