<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><h1 style="background-color: rgb(255, 255, 255);" class=""><pre style="font-size: 12px; font-weight: normal;" class=""><pre style="white-space: pre-wrap;" class="">All,</pre><pre style="white-space: pre-wrap;" class="">To see what the additional complexity of implementing the “safe module unloading” (as discussed in this thread) would be, I have implemented it.</pre><pre style="white-space: pre-wrap;" class="">Answer: About 10 lines of code (1 in ORG + 9 in Kernel) plus 10 lines in the tools module System.</pre><pre style="white-space: pre-wrap;" class="">It has been added to Experimental Oberon <a href="https://github.com/andreaspirklbauer/Oberon-experimental" class="">https://github.com/andreaspirklbauer/Oberon-experimental</a> :</pre><pre style="white-space: pre-wrap;" class=""><pre class=""><pre style="white-space: pre-wrap;" class=""> - Kernel.Scan0 and Kernel.Scan (10 lines added at the end of procedure Scan0)</pre><pre style="white-space: pre-wrap;" class=""> - ORP.BuildTD (1 line added) and ORP.FindFlds (1 line changed, renamed from ORP.FindPtrFlds)</pre><pre style="white-space: pre-wrap;" class=""> - System.SecureFree (new command added)</pre></pre><div class="">So it is really quite straightforward. The additional complexity remains within tolerable bounds.</div></pre><pre style="white-space: pre-wrap;" class="">It can of course be debated whether it makes sense to provide such an additional protection layer in the base system or whether "module life cycle management” should be handled at a higher level.</pre><pre style="white-space: pre-wrap;" class="">I would tend to argue for the latter. However, in the absence of an “application management” layer (and/or app store) in Oberon, it is nice to have the "secure version" of module unloading around as a separate command System.SecureFree (I kept it separate from the System.Free command for now, so that if users who want to *force* the unloading of a module, they can just continue to use System.Free).</pre><pre style="white-space: pre-wrap;" class="">For now it’s just a quick experiment - so I’d be interested in hearing about suggestions, potential improvements, etc. The documentation of Experimental Oberon (see the pdf file on its GitHub page) explains what I have done. But in a nutshell: I extended the information in the type descriptor with additional entries containing offsets to *procedure variables* of a record type, and combined the unloading with the scan phase of the garbage collector (so unloading a module automatically also collects garbage from the heap). Other ways to achieve the same goal are of course possible. For example, one might integrate it into (a modified version of) the routine for the *mark* phase instead, without actually collecting garbage in the process (which was the approach chosen in the Ceres version). It’s nice to play around with various approaches..</pre><pre style="white-space: pre-wrap;" class="">Andreas</pre><pre style="white-space: pre-wrap;" class=""><br class=""></pre><pre style="white-space: pre-wrap;" class="">- - -</pre><pre style="white-space: pre-wrap;" class=""><pre class=""><pre style="white-space: pre-wrap;" class=""><br class=""></pre><pre style="white-space: pre-wrap;" class="">(*) For the details see <a href="https://github.com/andreaspirklbauer/Oberon-experimental" class="">https://github.com/andreaspirklbauer/Oberon-experimental</a></pre><pre style="white-space: pre-wrap;" class=""><br class=""></pre></pre></pre></pre></h1></body></html>