Eclipse Community Forums: DSDP - Real-Time Software Components (RTSC) » statically inserting an instance handle into another module's mod state

Home » Archived » DSDP - Real-Time Software Components (RTSC) » statically inserting an instance handle into another module's mod state

Show: Today's Messages :: Show Polls :: Message Navigator

statically inserting an instance handle into another module's mod state [message #383146]

Wed, 29 July 2009 22:24

Shreyas Prasad

Messages: 3
Registered: July 2009

Junior Member

Champs--

I'd like to find out whether RTSC permits the following scenario:
ModA's module state contains an array of IModB handles. Statically
creating an instance of ModB1 which inherits from IModB should add the
instance's handle to ModA's handle array.

From ModA.xdc:

struct Module_State {
IModB.Handle handles[];
};

I'm not sure whether this is permissible because we don't have access to a
static handle until we are in ModB1's instance$static$init. By this time,
ModA's module$static$init has already been evaluated (per the order of
evaluation chart at
http://rtsc.eclipse.org/docs-tip/Creating_Configurable_Conte nt). Hence,
the module state has been sealed and we cannot insert the handle to the
ModB1 instance into ModA's module state.

Thanks,

Shreyas

Report message to a moderator

Re: statically inserting an instance handle into another module's mod state [message #432792 is a reply to message #383146]

Thu, 30 July 2009 17:20

Dave Russo

Messages: 172
Registered: July 2009

Senior Member

Shreyas Prasad wrote:
> Champs--
>
> I'd like to find out whether RTSC permits the following scenario:
> ModA's module state contains an array of IModB handles. Statically
> creating an instance of ModB1 which inherits from IModB should add the
> instance's handle to ModA's handle array.
> From ModA.xdc:
>
> struct Module_State {
> IModB.Handle handles[];
> };
>
> I'm not sure whether this is permissible because we don't have access to
> a static handle until we are in ModB1's instance$static$init. By this
> time, ModA's module$static$init has already been evaluated (per the
> order of evaluation chart at
> http://rtsc.eclipse.org/docs-tip/Creating_Configurable_Conte nt). Hence,
> the module state has been sealed and we cannot insert the handle to the
> ModB1 instance into ModA's module state.
>
> Thanks,
>
> Shreyas
>
Hummm, this might be a hole. Have you tried it?

Note that although instance#static$init is not called until very late,
the instance object itself already exists. So, it may be possible to
statically create an array of all instances of all modules that
implement a common interface.

Report message to a moderator

Re: statically inserting an instance handle into another module's mod state [message #435354 is a reply to message #432792]

Thu, 30 July 2009 20:53

Shreyas Prasad

Messages: 3
Registered: July 2009

Junior Member

Yes, I tried this in a past and got an error complaining that the module
state had been sealed (or something to that effect).

I don't really want to place all handles to instances of ModB in ModA's
instance state-- only those instances that have been appropriately
configured.

I think a workaround for this problem is to create a non-meta module
config in ModA that 'stores' the handles (plus additional information sent
by ModB1's instance$static$init). In ModA's Module_Startup I will memcpy
this stored information into its module state.

Report message to a moderator

Re: statically inserting an instance handle into another module's mod state [message #437035 is a reply to message #435354]

Fri, 31 July 2009 01:01

Dave Russo

Messages: 172
Registered: July 2009

Senior Member

Shreyas Prasad wrote:
> Yes, I tried this in a past and got an error complaining that the module
> state had been sealed (or something to that effect).
>
> I don't really want to place all handles to instances of ModB in ModA's
> instance state-- only those instances that have been appropriately
> configured.
>
> I think a workaround for this problem is to create a non-meta module
> config in ModA that 'stores' the handles (plus additional information
> sent by ModB1's instance$static$init). In ModA's Module_Startup I will
> memcpy this stored information into its module state.
>
This should also fail. If the module state (which should be module
private data) is sealed, the module configs (which are global variables)
should also be sealed.

An alternative that avoid the memcpy() and duplicate data on the target
is to add a template to the module (see
http://rtsc.eclipse.org/docs-tip/XDCspec_-_%40Template) and generate the
table yourself - remember to use long name sin the template to ensure no
symbol names clashes. Then, in lieu of using module state to access
this static list, simply reference your generated table directly.

A second alternative (which may not work in your situation) is to not
use the instance state to select the list and instead use the instance's
creation parameters to select the appropriate items. Again, this is
known well in advance of the instance$static$init() call.

Report message to a moderator