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

[John W. Eaton]

On 11-Jun-2008, Michael Goffioul wrote:

| 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).

I guess I'm not following what you mean by a "DLD class".

jwe