octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Goffioul
Subject: Re: "clear all" problem for classes defined in oct-files (Was: : bug) (Concerns: SWIG)
Date: Wed, 28 May 2008 10:54:56 +0200

On Wed, May 28, 2008 at 7:43 AM, Xavier Delacour
<address@hidden> wrote:
> On Mon, May 26, 2008 at 11:16 AM, Michael Goffioul
> <address@hidden> wrote:
>> Note: this problem occurs in 3.0.1, but I could not check if it was present
>> in development code (it happens with SWIG-based code, but SWIG
>> support for octave is only available for 3.0.x branch, AFAIK).
>
> I haven't been working on head, but I imagine it should work without
> any problems. (or at least I'm not currently aware of any). I'll give
> it a try when I get a chance.

No, it does not work out-of-the-box (I already tried a few weeks ago).
The symbol table code has completely been revamped.

> Won't any oct-file that installs a custom type have this problem if
> variables of that type are installed in the global symbol table? Off
> hand it seems like the correct solution is to swap steps 2 and 3. Or
> unload symbols etc in step 2, but only unload the shared libs in a new
> step 4.
>
> I think this is only SWIG specific in that it installs a global
> variable at load time. Other packages that use custom types probably
> have the same problem, but you have to assign a global variable of the
> custom type to notice it.
>
> You should also see a similar problem if you touch an oct-file that
> has installed a custom type (and an instance of it exists somewhere).
> Octave will try to reload the oct-file and make the type invalid.. and
> subsequently using the existing variable instance will cause a crash.

Win32 platform is slightly different about this, in the sense that you can't
modify (or delete) a shared module that is mapped by some process.
So as long as an oct-file is loaded by octave, you can't touch it.

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

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]