[Oberon] Oberon for a C++ user.

[Srinivas Nayak]

> Wojtek: I think that the most conservative solution is #2:
> 2. Check for references and don't unload if there are any.

I liked this idea very much.

Can this be of any help?
http://lists.inf.ethz.ch/pipermail/oberon/2016/009916.html


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 10/07/2016 12:52 AM, Skulski, Wojciech wrote:
> 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=
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>