Re: crashes when exiting octave and loading swig-wrapped code

[John W. Eaton]

On  3-Nov-2009, Jaroslav Hajek wrote:

| I inspected the code a bit, and the basic obstacle I see is the
| octave_shlib::close method, which runs a hook function for each
| registered function, and then forces dlclose() (or equivalent), even
| though there may still be references to the shlib object.
| 
| John, can you give me a clue why this is so?

It was probably just a mistake caused by originally thinking that the
only thing that would be loaded would be some functions that didn't
create global or otherwise persistent data structures.  In that case,
I think it would always be OK to unload/reload without worrying about
reference counts.

| I would imagine a more straightforward implementation of octave_shlib,
| being merely a reference-counted pointer to the library handle (or
| zero). Then, dlclose would simply be called when the reference count
| drops to zero - similar to array and all the other reference-counted
| stuff.
| 
| If this were true, classes defined via .oct files could simply attach
| a copy of the originating octave_shlib into the class, ensuring that
| the library won't be unloaded.

Seems OK to me.

| This could result in multiple loads of the same file into memory, if
| it was modified after loading, but I didn't find any information that
| this is not possible.

If there is some global state created, I think it could cause trouble
to load multiple copies.  So maybe it would be better to simply refuse
to reload unless the previous copy can be safely unloaded (i.e., the
reference count is zero?).

jwe