From Stanley.Ho at sun.com Wed Aug 8 11:58:26 2007 From: Stanley.Ho at sun.com (Stanley M. Ho) Date: Wed, 08 Aug 2007 11:58:26 -0700 Subject: Module system notification mechanism In-Reply-To: <46A8F636.20609@oracle.com> References: <4684078C.6030907@oracle.com> <4684425F.4060308@sun.com> <4697C8A2.40407@oracle.com> <469BC7FA.5080406@sun.com> <469BD808.90207@oracle.com> <469C1697.2090403@sun.com> <469CFC51.3020109@oracle.com> <469D3932.4060000@sun.com> <469DB742.4000204@oracle.com> <46A01F4F.7040300@sun.com> <46A108CE.7020606@oracle.com> <46A72A2E.5090406@sun.com> <46A8F636.20609@oracle.com> Message-ID: <46BA1252.9010408@sun.com> Hi Bryan, Bryan Atsatt wrote: > Sorry, but this makes no sense to me. When a module transitions from > RESOLVED to READY, it is, by definition, prepared to execute any of its > code, including calls into dependent modules. And this is true even in > the case of cyclic dependencies; otherwise, we could not hand out a > module for use at this point either! > > So all we have to do is call initialize() as the last step before > transitioning to READY. If it fails, we go to ERROR, else go to READY. I'm afraid it's more complicated than that. Even if a module is in resolved state, the imported modules might still be in the middle of initialization. The question is when a module's initializer is called, what kind of state do we expect its imported modules to be in? I think the semantic we want is that the imported modules should have been initialized (meaning their initializers should have been called) when the current module's initializer is invoked, so we won't run into weird situations where the imported modules are only half-initialized when they are accessed by the importer's initializer. However, when cyclic dependencies are involved, I don't think we can support this semantic for all imported modules. This was why I suggested when an initializer in a module attempts to access the imported modules, we make no guarantee that *all* imported modules are fully initialized and accessible in all situations. In other words, we can only guarantee that the initializer can access those imported modules that are fully initialized at that point. > We definitely need to document this with some care. But, again, the only > real potential issue here is with cycles, just as it is during > initialization. In the absence of cycles, the release() calls will occur > in the correct order, right? That is, if > > A --depends--> B --depends--> C > > And C is released, the importers will be released first: A, then B, and > finally C. Sounds right. > As long as we guarantee this ordering, the potential issues will be > reduced to those due to cycles. And, again, just as with > order-of-static-initialization, developers must be aware of the pitfalls > of cycles and code around them. The potential issue will also arise whenever the importer and the imported modules have different semantics on release(). If C attempts to shutdown itself when release() is called, while B simply treats it as a no-op, it is possible that B might still attempt to access C afterwards because B might have no knowledge of what C is doing internally. We'll need to document this so developers will be aware of the issues. - Stanley From bryan.atsatt at oracle.com Sat Aug 18 14:33:17 2007 From: bryan.atsatt at oracle.com (Bryan Atsatt) Date: Sat, 18 Aug 2007 14:33:17 -0700 Subject: Module system notification mechanism In-Reply-To: <46BA1252.9010408@sun.com> References: <4684078C.6030907@oracle.com> <4684425F.4060308@sun.com> <4697C8A2.40407@oracle.com> <469BC7FA.5080406@sun.com> <469BD808.90207@oracle.com> <469C1697.2090403@sun.com> <469CFC51.3020109@oracle.com> <469D3932.4060000@sun.com> <469DB742.4000204@oracle.com> <46A01F4F.7040300@sun.com> <46A108CE.7020606@oracle.com> <46A72A2E.5090406@sun.com> <46A8F636.20609@oracle.com> <46BA1252.9010408@sun.com> Message-ID: <46C7659D.7000307@oracle.com> Stanley M. Ho wrote: > Hi Bryan, > > Bryan Atsatt wrote: >> Sorry, but this makes no sense to me. When a module transitions from >> RESOLVED to READY, it is, by definition, prepared to execute any of its >> code, including calls into dependent modules. And this is true even in >> the case of cyclic dependencies; otherwise, we could not hand out a >> module for use at this point either! >> >> So all we have to do is call initialize() as the last step before >> transitioning to READY. If it fails, we go to ERROR, else go to READY. > > I'm afraid it's more complicated than that. Even if a module is in > resolved state, the imported modules might still be in the middle of > initialization. The question is when a module's initializer is called, > what kind of state do we expect its imported modules to be in? > > I think the semantic we want is that the imported modules should have > been initialized (meaning their initializers should have been called) > when the current module's initializer is invoked, so we won't run into > weird situations where the imported modules are only half-initialized > when they are accessed by the importer's initializer. However, when > cyclic dependencies are involved, I don't think we can support this > semantic for all imported modules. > > This was why I suggested when an initializer in a module attempts to > access the imported modules, we make no guarantee that *all* imported > modules are fully initialized and accessible in all situations. In other > words, we can only guarantee that the initializer can access those > imported modules that are fully initialized at that point. I agree (this is the order-of-static-initialization type problem I referred to earlier). > >> We definitely need to document this with some care. But, again, the only >> real potential issue here is with cycles, just as it is during >> initialization. In the absence of cycles, the release() calls will occur >> in the correct order, right? That is, if >> >> A --depends--> B --depends--> C >> >> And C is released, the importers will be released first: A, then B, and >> finally C. > > Sounds right. > >> As long as we guarantee this ordering, the potential issues will be >> reduced to those due to cycles. And, again, just as with >> order-of-static-initialization, developers must be aware of the pitfalls >> of cycles and code around them. > > The potential issue will also arise whenever the importer and the > imported modules have different semantics on release(). If C attempts to > shutdown itself when release() is called, while B simply treats it as a > no-op, it is possible that B might still attempt to access C afterwards > because B might have no knowledge of what C is doing internally. We'll > need to document this so developers will be aware of the issues. Yep. > > - Stanley >