[Oberon] Oberon for a C++ user.

Peter Fröhlich peter.hans.froehlich at gmail.com
Thu Oct 6 22:06:12 CEST 2016


On Thu, Oct 6, 2016 at 11:45 AM, chris <chris at gcjd.org> wrote:
> There can be different versions of code for the same procedure  around
> at the same time after an unload / reload cycle of a module.

The question is what exactly "around" means. In my original proposal I
mentioned "RCU" as an example. The idea is that whoever *has* a
procedure variable reference to the "unloaded" module at the time
unloading was requested will keep that reference. However, when they
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 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.
-- 
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

The views stated in this communication are my own and do not express
the position or views of The Johns Hopkins University.


More information about the Oberon mailing list