Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DSDP - Real-Time Software Components (RTSC) » ModA changing ModB's module parameters
ModA changing ModB's module parameters [message #1248] Fri, 20 February 2009 15:20 Go to next message
Todd Mullanix is currently offline Todd Mullanix
Messages: 8
Registered: July 2009
Junior Member
I have a question about one module changing another modules config
parameter. More explicitly, when it changes a front-end module that then
pushes its config parameter to a delegate. Are there any rules for this?

Let’s take a look at an example

ModA uses ModB. ModA increments one of ModB’s module wide config
parameter (e.g. maxRuntimeEntries)
ModB is the front end for different implementations (e.g. Bios impl.,
Linux impl, etc.). Let’s call the delegate ModBDelegate.

I have ModB pushing its module config parameter to ModBDelegate in its
module$use.
ModB.Proxy.delegate$.maxRuntimeEntries = ModB.maxRuntimeEntries; // proxy
is ModBDelegate


The maxRuntimeEntries can be changed (e.g. set, incremented, decremented)
in the app’s cfg file and that works fine. How can ModA change the
setting? There is no order guarantee, so it cannot do it in it’s
module$use (since ModB could have already pushed the setting to
ModBDelegate).

Should ModA be restricted to setting the module config parameter in
module$meta$init (or instance$meta$init)? Or should ModB change the way it
is pushing the parameter to the delegate? Or should the delegate pull it
from the front-end when it needs it (e.g. in ModBDelegate’s
module$static$init)?

Thanks,
Todd
Re: ModA changing ModB's module parameters [message #1296 is a reply to message #1248] Fri, 20 February 2009 21:23 Go to previous message
Bob Frankel is currently offline Bob Frankel
Messages: 10
Registered: July 2009
Junior Member
i could be wrong, but if ModA truly *uses* ModB (and this static
relationship is captured in package requires statments), then we can
ensure that ModA's module$use will run be ModB's module$use....


Todd Mullanix wrote:
> I have a question about one module changing another modules config
> parameter. More explicitly, when it changes a front-end module that
> then pushes its config parameter to a delegate. Are there any rules for
> this?
>
> Let�s take a look at an example
>
> ModA uses ModB. ModA increments one of ModB�s module wide config
> parameter (e.g. maxRuntimeEntries)
> ModB is the front end for different implementations (e.g. Bios impl.,
> Linux impl, etc.). Let�s call the delegate ModBDelegate.
>
> I have ModB pushing its module config parameter to ModBDelegate in its
> module$use.
> ModB.Proxy.delegate$.maxRuntimeEntries = ModB.maxRuntimeEntries; //
> proxy is ModBDelegate
>
>
> The maxRuntimeEntries can be changed (e.g. set, incremented,
> decremented) in the app�s cfg file and that works fine. How can ModA
> change the setting? There is no order guarantee, so it cannot do it in
> it�s module$use (since ModB could have already pushed the setting to
> ModBDelegate).
>
> Should ModA be restricted to setting the module config parameter in
> module$meta$init (or instance$meta$init)? Or should ModB change the way
> it is pushing the parameter to the delegate? Or should the delegate pull
> it from the front-end when it needs it (e.g. in ModBDelegate�s
> module$static$init)?
>
> Thanks,
> Todd
>
>
Previous Topic:Changing library suffix
Next Topic:correct way to set profile for executable
Goto Forum:
  


Current Time: Fri Oct 31 19:28:24 GMT 2014

Powered by FUDForum. Page generated in 0.01626 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software