gitlab.com/jokerrs1/Sia@v1.3.2/doc/Modules.md (about)

     1  Module Conventions
     2  ==================
     3  
     4  Each module has a file/directory where they store persistent data (if
     5  necessary). When module.New is called, the module is responsible for creating
     6  and populating that directory. The logic for saving and loading data belongs in
     7  persist.go.
     8  
     9  Modules that depend on external information (such as the state of consensus)
    10  have an update.go to manage fetching and integrating the external information.
    11  If that information is coming from another module, a subscription should be
    12  used. Module subscription uses a ModuleSubscriber interface (which the
    13  subscriber must satisfy) and a ModuleSubscribe method (implemented by the
    14  parent module). As the parent module gets updates, it will call
    15  ReceiveModuleUpdate (the only method of the ModuleSubscriber interface) on all
    16  subscribers, taking care that each subscriber always receives the updates in
    17  the correct order. This method of subscription is chosen to keep information
    18  flow simple and synchronized - a child module should never have information
    19  that the parent module does not (it just causes problems).
    20  
    21  For testing, it is often important to know that an update has propagated to all
    22  modules. Any module that subscribes to another must also implement a
    23  ModuleNotify function in subscriptions.go. ModuleNotify returns a channel down
    24  which a struct{} will be sent every time that module receives an update from a
    25  parent module. To keep things simple, a module should not subscribe to the
    26  parent of another module that it is subscribed to. For example, the transaction
    27  pool is subscribed to the consensus set. Therefore, no module should subscribe
    28  to both the transaction pool and the consensus set. All consensus set updates
    29  should be received through the transaction pool. This helps with
    30  synchronization and ensures that no child module ever has information that the
    31  parent module has not yet received (desynchronization).
    32  
    33  #### Module Update Flow
    34  
    35  consensus -> (host, hostdb, renter, (transaction pool -> miner, wallet))