[Oberon] ETH Oberon/Gadgets: System Freeze in unloading

[Douglas G. Danforth]

Felix Friedrich wrote:
> 
> Hi Patrick
> 
> >However, in several years of working with Oberon, I have only found three
> >ways to produce C-like system freezes
> >apart from using the unsafe SYSTEM feature:
> >A) calling C programs from within Oberon
> >B) passing very large arrays as value parameters in procedure headings
> >C) unloading modules whereby some visual gadget is still hanging around
> >somewhere, as mentioned above.
> >I feel system stability is a prominent one of the many highlights of
> >Oberon, so the points B and C hurt the more...
> 
> I agree. By the way problem B) occurs because the max stacksize of an
> Oberon.Thread (in Windows) is approx. like 100kB. I have increased that
> value to 1MB in my threads, but anyway, the best "solution" is to take
> VAR-pars or Pointers. As far as I know, in Windows-Oberon it is a
> Windows-Problem, since the Windows-thread crashes when the size of the
> stack is too small. Maybe there should be some built in range-check for the
> stack in Oberon. (possible?)
> Do you see a solution for C) ?

I would think the simplest solution would be to tie a visual 
gadget to the module that created it.  Freeing of that module
could then not occur as long as an instance of the gadget
occured anywhere.

Its been a while since I looked at how gadgets are implemented
and am a little surprised by this thread.  Every visual instance
should have a pointer associated with it and hence memory allocated.
Kill the visual instance=> kill the pointer (mark it for garbage 
collection) and  kill the pointer=>kill (remove) the visual instance.
Why isn't this done?

-Doug