[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: More about packaging (fwd)
- From: Mike Pall <mikelu-0406@...>
- Date: Sun, 6 Jun 2004 19:38:23 +0200
about "unloadlib" ...
Well, let's face it:
- 99.9% of all developers will never need this because 99.9% of all apps
have a static working set of libraries.
- Those who need it, know what they are doing. They will take extra
precautions to remove all references to the library before unloading.
- An extensive framework to support automatic unloading is very difficult
to get right and will not benefit most developers.
[I'm not putting down your solution, Edgar. I just don't think we need
a general solution of that proportion.]
- There is no way we can prevent everyone from shooting themselves in the
foot. There are far more loopholes than we could possibly close.
- Both perl and Python do not have such a feature. The import/require/use
statements and the associated library management never unload libraries.
But both provide a low-level way to explicitly load/unload a dynamic
library file. And the docs state that you need to be extra careful
if you give any such library reference to the hands of the internal GC
and then try to unload the library.
- Lua is a lightweight framework that should promote lightweight solutions.
The current solution already passes a handle to the library as an upvalue
to the function loaded from the library. So this function has the ability
to provide support for unloading. It's just that no libraries I know of do
that. Maybe because it's undocumented?
Another possibility would be to add the library handle (lightuserdata) as
a second return value to loadlib(), so you can write:
func, handle = loadlib(...)
[carefully destroy all references to library]
That would be real simple to implement, but I don't know whether this is
really needed. If you write your own libraries you might as well provide
an _unload() function in your function table. If third-party libraries
do not provide such a function then they are probably not safe to unload.
Anyway, I second Asko Kauppi's request for use cases. Can we please have
an indication whether this is an issue about own libraries or third-party
libaries in general?
And about the danger of crashing Lua: If you can use loadlib(), you can
always provoke a crash by referencing an innocent symbol:
loadlib("libc.so.6", "read")() -> Segmentation fault
So I think this is a non-issue.
BTW: Is there a bug tracker for Lua? While experimenting with this I
discovered by accident that ...
debug.getupvalue(function() end, 0)
... crashes Lua 5.0.2 and 5.1-work0 due to a missing range check in