atom feed67 messages in org.python.python-listAmigaDOS threads (was: Re: killing th...
FromSent OnAttachments
32 earlier messages
Jp CalderoneJan 24, 2003 11:53 am 
Paul RubinJan 24, 2003 12:14 pm 
Peter HansenJan 24, 2003 1:34 pm 
Peter HansenJan 24, 2003 1:36 pm 
Peter HansenJan 24, 2003 2:20 pm 
Paul RubinJan 24, 2003 2:31 pm 
Peter HansenJan 24, 2003 2:39 pm 
Tim PetersJan 24, 2003 3:05 pm 
Terry ReedyJan 24, 2003 3:20 pm 
Uwe SchmittJan 24, 2003 3:38 pm 
Paul RubinJan 24, 2003 4:58 pm 
"Martin v. Löwis"Jan 24, 2003 6:14 pm 
"Martin v. Löwis"Jan 24, 2003 6:19 pm 
Laura CreightonJan 24, 2003 6:25 pm 
Terry ReedyJan 24, 2003 7:10 pm 
Jp CalderoneJan 24, 2003 7:38 pm 
Paul RubinJan 24, 2003 8:29 pm 
Christian TismerJan 24, 2003 8:42 pm 
Martin v. LöwisJan 25, 2003 3:23 am 
Tim PetersJan 25, 2003 4:14 am 
Ype KingmaJan 25, 2003 4:34 am 
Paul RubinJan 25, 2003 4:40 am 
Tim PetersJan 25, 2003 5:28 am 
Martin v. LöwisJan 25, 2003 5:57 am 
Irmen de JongJan 25, 2003 4:51 pm 
Jacob HallenJan 27, 2003 2:22 am 
Skip MontanaroJan 27, 2003 7:13 am 
AahzJan 27, 2003 7:26 am 
Skip MontanaroJan 27, 2003 7:49 am 
anton wilsonFeb 11, 2003 10:14 am 
Peter HansenFeb 11, 2003 10:57 am 
anton wilsonFeb 11, 2003 1:06 pm 
Peter HansenFeb 11, 2003 1:10 pm 
Laura CreightonFeb 11, 2003 3:31 pm 
anton wilsonFeb 12, 2003 8:06 am 
Subject:AmigaDOS threads (was: Re: killing thread ?)
From:Irmen de Jong (irm@NOSPAM-REMOVETHIS-xs4all.nl)
Date:Jan 25, 2003 4:51:30 pm
List:org.python.python-list

Dennis Lee Bieber wrote:

Or, to use Amiga terms, the bottom of the hierarchy was an Exec task; AmigaDOS processes were tasks with extra data in the task control block -- primarily entries for stdin, stdout, and some other AmigaDOS level data (Exec was the task switch/memory allocation/IPC [messages] kernel library; I/O and other stuff were libraries built using Exec capabilities. AmigaDOS was the "user level" view, the shell commands and file concepts.)

You're right ofcourse. Though I always refer to the Amiga's OS with "AmigaDOS". Others use "Kickstart", which was actually the name for the 512Kbyte ROM that contained the core OS. ;-)

In a way, the Exec message port and signal bits were a close match to DEC VMS mailboxs (with the above "zero-copy" constraint -- what was passed was a list node with the address of the message data) and process local event flags (local, as you could not share a signal bit between tasks -- though there likely was some scheme by which one task could locate/modify the bits of another).

I don't know much about VMS, but I do know that a lot of nice stuff was borrowed from VMS (and Unix) and used in the creation of AmigaDOS. ( 'Assigns' , anyone?)

Of course, even signal bits were only effective if the program explicitly checked them -- a common problem for neophyte coders is that <ctrl-c> had no effect on a process bound loop as the signal check was done as part of the C I/O library.

while (1) x = y;

could not be broken from the command line as it never tests the signal bits.

You hit the nail on the head. Thanks for pointing this out again. Because of this requirement, the SIGNAL solution for aborting a thread, proposed elsewhere in this discussion, would never work on the Amiga if the thread doesn't check for the signal explicitly.

Though I now remember the following: it was possible to set a special function for a designated "interrupt" signal. (there is a field for this in the Exec task structure). I even used this in AmigaPython to catch and process the CTRL-C (or "break") signal, if I'm not mistaken. So it might be possible after all!

Well, it doesn't matter anymore. AmigaPython died at version 2.0, without thread support. ;-)