Re: Problem with intertask comm

[Ted Dennison<dennison@telepath.com>]

In article <3ad62703$0$190$456d72a3@news.skynet.be>, Tom De Muer says...
>Thanks for the advice...  I'll go for the Unchecked_Access because basically
>I'd like to do the following:
>  - Create some listener/sender tasks X(1..n)
>  - Create some sender/listener tasks Y(1..m)
>I want to _dynamically_ assign a listener to a sender.  And if I destroy the
>listener/sender tasks before I destroy the sender/listener tasks i'll have a
>problem but I don't see how I can do this otherwise.  If I declare for
>instance the first class of tasks at a higher scope I can't access the
>second class of tasks which are at a lower scope so I could not assign a
>listener to a sender... the tasks thus have to be on the same level of scope
>to be assigned a reference to each other, or am I wrong?

Sort of. Their access value objects have to both be on the same scope as their
access type for 'access to work. They both have to be at the same scope in the
same package, or at some mutually-accessable scope in separate package specs, in
order to know about each other.

As a separate issue, you might want to consider a setup where tasks don't get
destroyed and new ones created later, but they just go into some quiescent state
until they get a new partner. Generally its a Bad Thing to go around destroying
task type objects and creating new ones repeatedly. Ada has to keep some
information about deallocated tasks around so that stuff like 'terminated will
work. That can cause a memory leak. Note that doing this will also solve your
access value scope problem, as no task will ever go out of scope (barring
unhandled exceptions).



---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com