[Oberon] Oberon for a C++ user.

[Skulski, Wojciech]

Chris:

  I think that the most conservative solution is #2:

2. Check for references and don't unload if there are any.

The system should then complain in the Log "Cannot unload module <Name> because its procedures are still in use" or something to that effect. The programmer, who is developing the code, will be able to figure out that s/he installed these procedures somewhere.

Here is another thought: BlackBox has the FINALIZE section of the module. Perhaps it is the place where the checks could be performed? If the use of the exported procedures could be traced back in the FINALIZE section, then the finalizer can raise a trap. Trap in the finalizer would abort unloading the module. 

I am not sure how it relates to Andreas' work. Any comments?

W.
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of chris [chris at gcjd.org]
Sent: Thursday, October 6, 2016 2:31 PM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Oberon for a C++ user.

On Thu, 6 Oct 2016 16:15:46 +0000, Skulski, Wojciech wrote:
> 1. Find all the references to the old (still loaded) code.
> 2. Get rid of the references.

That's the problem. How do you get rid of the references in procedure
variables?

Normal garbage collection does not deallocate the memory until all
references to the memory block have vanished by the usual progress of
the program. Until that has happened the old code is still available
unless you do anything to eliminate the references.

> Now you are ready to load the fresh code. At any given time there is
> only one copy of the code loaded to RAM. Since all is being done by
> the GC, and the machine is a single threaded machine with no
> preemption, it is not possible to interrupt the process.

That's not what I meant. The garbage collector in it's standard way
does not remove any references; it just checks them and deallocates
only heap blocks that don't have any references anymore.

If there are still references and you reload a modified module again
you have two incarnations of the module in the system.

In the end I see these possibilities.

1. Don't care, just unload like it currently is.

2. Check for references and don't unload if there are any.

3. Unload only removes the module from the module list. Check for
references and unload the code later from the garbage collector when no
references exist anymore.

4. Check for references and set them to NIL then unload.

5. Even more complicated ideas: like reload and unload in one step to
replace the references to the same procedures in the new module, a kind
of dynamic relinking.
I don't really suggest this, because this causes new problems if the
new module does not have the same procedures as the old one and binding
is done by name things get really messy.

I hope I have explained it better now. And obviously the problem is not
so easy to solve not because of it's implementation but because it's
not obvious how it should work correct.

Greetings, chris
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=x1NIqMPi2VYn-rP6tryogccwOa36_ecIpb2Xzbmq1zI&s=2-9Tq1InWQ8qoQ4qwmLjNPxvgjhhnQLt-qm9KKYbgRI&e=