Module system notification mechanism

[Stanley M. Ho]

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