ford@crash.CTS.COM (Michael Ditto) (06/20/87)
In article <1402@ulowell.cs.ulowell.edu> page@ulowell.cs.ulowell.edu (Bob Page) writes: >qix@ihlpa.ATT.COM (Ed Puckett) wrote: >>Does a Task ID ever get reused from reboot to reboot? If not, >>then ID-handler is unnecessary, and Task IDs will work fine. > >They get reused. How about task ID + timestamp? That should be >pretty unique. The problem I see is with sending a message to another task. How can you verify that (A) a message port still exists at the same address, and (B) that is is really "the same" message port (i.e. belongs to the same task). The timestamp idea would work if there were a timestamp (or other unique ID) in the MsgPort structure, but there isn't. You can have a convention between two processes, which says that a message must contain a pre-arranged unique ID to be considered valid, but if that process exits, and another one pops up and gets the same message port, the new process will be very confused about the unexpected messages it gets. It would probably be a good idea if FreeMem zeroed out the first few bytes of a freed block, that would make the ln_Type field of most things become invalid, and at least you could know not to send a message to anything that is not a message port. But that doesn't fix the example above, where that same chunk of memory becomes someone else's message port. In practice, these things are not real problems, because of the way the Amiga works; generally, a task will send a message and Wait for the reply, and since there is no way to kill a task, you don't have to worry about it not being there to receive the reply. But I imagine there are situations that can be dangerous. Anyone have any examples of pitfalls in this area, or ideas for solutions? -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu try: or: /bin/csh -fc 'Got a light?' /bin/ar t god