[Oberon] Oberon for a C++ user.

[chris]

On Thu, 6 Oct 2016 16:06:12 -0400, Peter Fröhlich wrote:
> create a new reference, for example by executing
> 
> myVar := nameOfModule.nameOfProcedure;
> 
> the will use the newly loaded "replacement" module. I am *assuming*
> that some part of Oberon keeps a list that maps module names to loaded
> "module objects" as it were. When you "unload" you remove that entry.
> This may or may not also unload the module data structure underneath.
> But the next time someone wants to access that module, it get loaded
> "fresh" and is entered into that list of "currently loaded modules"
> and so on. As references to the old code get changed, eventually the
> GC decides that it's safe to really remove the old stuff.

I agree. That's the way a garbage collector should handle this.

But there are problems like a set of global variables which must live 
until the last procedure reference vanishes. So we have several sets of 
globals for one module name in memory at some time and then you mention 
global external resources, which is a related problem I think:

> I do, however, see a new problem now. Say module X has a procedure
> variable holding a reference to Y.P; however, module Y as part of it's
> "startup" also requested exclusive access to some resource, maybe Y is
> a device driver of sorts. Now we "unload" Y but since there's still a
> reference to it, we cannot *really* remove it. For Y.P to keep
> working, Y needs to still "own" the hardware it controls. When we try
> to load Y again, the above mechanism will work fine UNTIL the new Y
> tries to get control of the piece of hardware it's supposed to manage.
> Oops. So there may be a more complex "resource management story" that
> needs taking care of. I had not considered that yet.

I believe it is accepted that lower level modules of the Oberon system 
cannot be unloaded.

What do you think about this for unloading:

1. Remove the module from the list of loaded modules.

2. Add the module to a (new) list of unloaded modules which only has 
weak pointers to the modules resources.

3. Wait for the garbage collect to do it's work. If the last reference 
vanishes remove the module from the list of unloaded modules.

Loading is changed so that the system refuses to load a module that is 
in the unloaded list.

I hope that the user can usually fix this situation by unloading other 
related modules so that garbage collection can take place to have a 
safe and usable way of operation.

As an action of last resort a forced unload function could be 
implemented that writes NIL to all remaining references.

Greetings, chris