bader@spice.cs.cmu.edu (Miles Bader) (08/29/88)
In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: >In article <8808272322.AA03740@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>: [somebody besides Matt writes] >>: An idea central to the Amiga >>:is that an address in any tasks address space is not a virtual >>:address but a physical memory address. That means that you can hand >>:a pointer off to another task and it will be valid in THAT tasks's address >>:space. > >> Yes, this *IS* a nice idea. > >Personally I think this is the single biggest problem with the Amiga. For >a process running in a multitasking environment, it is akin to living in >a society where it is perfectly acceptable for strangers to walk up to you >at any time and stick their fingers in your mouth to examine your teeth. >There is absolutely no concept of enforced privacy between processes. Having a single address space is not equivalent to having unprotected, physical memory. You could have virtual memory (still one address space, but now larger than physical memory), with each task's memory only writeable be itself, and still get the advantages of the amiga's fast ipc. It wouldn't be totally trivial I expect, but the amiga seems far better suited to it than other non-mm oses. For instance, do people routinely WRITE to memory pointed to by Messages that they receive? This would create problems since the message & whatever it points to are still only writeable by the sender, and it would be both expensive and difficult [do to pagesize oriention of memory protection schemes, and the unkown extent of referenced data] to move protections every time you sent a message. I was under the impression that the normal use of messages was to simply send another message as the reply anyway. You would probably want to keep around per-task memory allocation data, since protected memory is probably handed out in pages, and the task should have to deal with this detail. -Miles
phils@tekigm2.TEK.COM (Philip E Staub) (08/29/88)
In article <2819@pt.cs.cmu.edu> bader@spice.cs.cmu.edu (Miles Bader) writes: [... deleted ...] > >For instance, do people routinely WRITE to memory pointed to by Messages >that they receive? This would create problems since the message & whatever >it points to are still only writeable by the sender, and it would be both >expensive and difficult [do to pagesize oriention of memory protection >schemes, and the unkown extent of referenced data] to move protections every >time you sent a message. I was under the impression that the normal use of >messages was to simply send another message as the reply anyway. > [... deleted ... ] > >-Miles You bet people write to memory pointed to by messages they receive! That's what happens every time you do a disk read, for example. The device driver gets a message with a pointer in xxx->io_Data which is used as the recepticle for data read from the disk. Consider the alternative: the driver would have to reply the message it received, then originate another message with the pointer to the buffer it read the data into, which the caller of the device driver would copy the data from into its own buffer. Then it would have to reply the message to the device driver. UGLY! Now, I've used another message passing operating system which *sort of* works around this by having the kernel copy the message from one task's memory space to the other. Of course, you pay the price: it's slower, and in the case of this particular operating system, the default is *not* to require a reply for each message. It actually requires a bit of a bubble in their kernel to provide for replies without setting up two message ports for each communication channel (one for the outgoing message, the other for the reply). But that's another story. -- ------------------------------------------------------------------------------ Phil Staub Tektronix, Inc., Vancouver, Washington 98668 phils@tekigm2.MEN.TEK.COM