I believe there are only a few (maybe one?) case(s) where the Ruby initialization dependencies are pretty ugly. The one I know about is a dependency between the Ruby network and the topology class. Given the limited scope of the problem, I think Steve's null init function should suffice.
-Derek On Mon, Jul 13, 2009 at 7:19 PM, Steve Reinhardt<ste...@gmail.com> wrote: > There's no real control over ordering... I believe init() is called on > objects in the same order that they were constructed, but you don't have a > lot of control over the construction order (short of the fact that if B is a > parameter to A then B will be constructed first) and it's probably best not > to rely on that anyway. > > There are ways to fix this that we've discussed in the past, but we never > implemented any of them. If there's a real need we could do that. However, > there are a couple of other approaches that are simpler if they apply. Say > for example that B's initialization needs some information from A: > > - Does B need A to be fully initialized, or does it just need to acquire > some basic information? In the latter case, as long as A can do enough in > its constructor to keep B::init() happy, then that will just work since > B::init() won't be called until after all the objects have been created. I > know Nate won't like this, and it is a bit fragile since some later person > who adds more complex calls to A in B::init() might be surprised, but a more > pragmatic programmer might be content with putting appropriate comments in > A::A() and B::init() to head off that scenario. > > - Are there are just one or a few special cases of 1:1 dependencies? If so, > I'd be tempted to defer B's initialization to a separate method, i.e., > B::init() could be a no-op, then at the end of A::init() call B::postAInit() > and of course at that point you know A::init() is done. > > If the dependencies are more general (e.g., there are a bunch of As that all > have to be fully initialized before any of a bunch of Bs) then we can look > at other solutions; if that's the case, please provide some more details on > just what the constraints are. It's also possible that perhaps it's the > partitioning of concepts into SimObjects that needs to be tweaked. For > example, off the top of my head it's not clear why "topology" would be a > SimObject, since SimObjects are generally fairly concrete things you could > point to on a block diagram. > > Steve > > On Mon, Jul 13, 2009 at 3:21 PM, Somayeh Sardashti <soma...@cs.wisc.edu> > wrote: >> >> Hi, >> >> Does M5 keep any order when calling init() of different objects? >> >> In Ruby, because of dependencies among some objects (like topology and >> network), the order of calling init() is important and handled in >> constructor of System (the main module). >> >> How can I keep this kind of ordering in M5? >> >> Somayeh > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
