[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: changes to path searching
From: |
John W. Eaton |
Subject: |
Re: changes to path searching |
Date: |
Fri, 27 Dec 2002 22:10:09 -0600 |
On 27-Dec-2002, Paul Kienzle <address@hidden> wrote:
| On Fri, Dec 27, 2002 at 02:52:29PM -0600, John W. Eaton wrote:
| > In octave_dynamic_loader::load, we search the currently loaded .oct
| > files for the symbol before actually loading the file, so yes, I think
| > this is still a problem. I suppose that instead of searching all the
| > currently loaded .oct files, we should only search the one that we are
| > currently loading (if it has already been loaded) otherwise, load it
| > and search. This requires maintaining a list of filename to dynamic
| > library handles in the dynamic loader module, but that is easy enough
| > to do. Would that solve the problem?
|
| That will only solve the problem if you can recognize that two files are
| the same. That should be easy enough, no? If it is a symbolic link,
| dereference it until you get to the base file, then check if that file is
| already loaded, otherwise load it. As a bonus, you don't have to search
| through all loaded files.
|
| This may make life slightly more difficult for some if they are relying on
| the fact that for example myconstructor() will automatically load all
| associated functions for their type and they don't need symlinks to
| myconstructor.oct.
|
| This will also make life difficult for a native windows port in that
| windows has dodgy support for symbolic links. I suppose I can write some
| special code for windows so that xxx.lnk is a text file which contains the
| relative path to the oct which exports the function. I'll worry about that
| when I have more time to work on the native port.
OK, I'm convinced that what we are doing now is not the right thing,
and my simple idea of a filename to shared library handle map also has
some problems.
So what should happen when we need to load functions from .oct files?
If running a function from a single file (say "foo" from "foo.oct")
actually installs multiple functions, then I think we can come up with
a simple solution that will work OK, at least until someone clears
some functions, updates a .oct file, or installs a new .oct file in the
path ahead of the old one (forcing a reload). Then I'm not sure what
should happen. Currently reloading forces all functions that have
been loaded from a single file to be cleared. But that will only work
if Octave was the one loading the functions into the symbol table --
if you do it with some code in your own loadable file, Octave won't
know about those functions, so it won't clear them. Then I think
closing the shared library and reloading could cause some trouble.
jwe