[Oberon] When is it safe to unload a module?

Chris Burrows chris at cfbsoftware.com
Mon Aug 6 00:41:18 CEST 2018

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Andreas Pirklbauer
> Sent: Saturday, 4 August 2018 12:54 PM
> To: ETH Oberon and related systems
> Subject: [Oberon] When is it safe to unload a module?
> Below are such *minimal* examples, covering all possible cases.
> In each case, the difference in output between Original Oberon (which
> does not address the issue at all) and Experimental Oberon (which
> fully solves this issue, including unloading of a *group* of module
> which only contains references among themselves) is shown.

Thank you for the examples. I tested them on other Oberon-related systems to see how they are handled there. These are the initial results:

1. BlackBox Component Pascal:

This is an 'industrial strength' system so I expected it to be the most defensive of any Oberon systems. It appears to attempt to unload the modules as a group. e.g I can unload M3 on its own but then subsequent calls e.g. 

Unload M2 

result in the error: 

M3 not found

(that’s right, M3 not M2)

So once you unload M3 you can't unload anything else. 

Unload M3 M2 M1 M0 

Works OK.

2. ETH Oberon for Windows:

Appears to be the same as Project Oberon. E.g. Example 2:

   M3.Init             # load M0, M1, M2, M3
   M3.SetGProc1        # set M1.gproc to M2.P (global procedure variable reference)
   System.Free M3 ~    # unload M3 successful
   System.Free M2 ~    # unload M2 successful (SHOULD NOT be successful (as ref from M1 to M2 exists))

When I run ShowModules M3 and M2 do not appear. However, I don't know if there is any other protection going on behind the scenes. What would I have to do to make the system crash after this sequence of calls to demonstrate the problem?


Chris Burrows
CFB Software

More information about the Oberon mailing list