1  #+TITLE: Story 13 - Module Space
 2  #+OPTIONS: author:nil date:nil
 3  
 4  This is a cautionary tale more than anything else, but it does affect how to
 5  design more complex objects.
 6  
 7  The summary message is, pay attention to the Module Space that an object and
 8  all its parts is owned by throughout its lifetime.
 9  
10  So what is the Module Space?  Very simply put, in a process that is made up
11  of parts that can be individually loaded and unloaded, each such part is a
12  Module, and anything it holds some kind of ownership of is part of its
13  space.
14  
15  Here's a practical example where this didn't have sufficient attention:
16  
17  - There are two pieces to this problem:
18  
19    - a main program, statically linked with lscore.a
20    - a plugin, statically linked with lscore.a
21  
22  - The main program set up an environment.
23  - The main program loaded a plugin, and called its startup routine.
24  - The plugin registered a number of algorithm implementations.
25    /This created the environment's implementation registration table under
26    the hood, and associated routines belonging to the plugin with it/
27  - The main program unloaded the plugin.  Before actually unloading, it's
28    stopper routine was called.  This removed the implementations from the
29    registration table /but didn't remove the table itself/
30  - The main program cleaned up the environment.  This tries to clean up all
31    the parts of the environment, including the implementation registration
32    table, /but its destructor was gone because the plugin itself was gone/
33  
34  This was solved by letting the environment itself be the creator of this
35  sort of global stuff, and the only way to get this sort of table is with a
36  call of the environment's dispatch function.  That ensures that such tables
37  are owned by the same Module as the environment itself (assuming normal
38  cleanup).
39