Re: "clear all" problem for classes defined in oct-files (Was: : bug) (Concerns: SWIG)

[Michael Goffioul]

On Wed, Jun 11, 2008 at 10:29 PM, John W. Eaton <address@hidden> wrote:
> On 28-May-2008, Michael Goffioul wrote:
>
> | Another solution for this kind of problem would be to prevent octave from
> | unloading an oct-file (this does not mean that the symbol cannot be removed
> | from the symbol table, but simply that the shared module is not unmapped
> | from the process address space) while there are still variables of classes
> | contained in the oct-file. One way to achieve this is to make all such 
> variables
> | to hold a reference to their containing oct-file, in the same way
> | octave_dld_function class does, by using octave_shlib. With automatic
> | referencing, the oct-file would only be unloaded when all functions and all
> | variables of a contained class are cleared. I think this would makes
> | things cleaner, and it could even be provided in octave by some standard
> | mechanism (like an octave_dld_base_value class, from which classes in
> | oct-files would inherit).
>
> Isn't this how things currently work?  I think the octave_base_shlib
> class manages this properly now, at least in the default branch (I
> have no plans to fix a problem like this in the release-3-0-x branch).
> But if not, then it would be helpful if someone could submit a simple
> test case that demonstrates the problem.

This works for DLD functions, but not for DLD classes. What I propose is to
extend this behavior to DLD classes, either on a per-class basis (every
DLD class must take care itself of the octave_shlib referencing) or through
an octave-provided mechanism (for instance in the form of an octave_dld_value
class).

Michael,