Re: Module finalization (along the lines of calling a function on exit)

[Rici Lake <lua@...>]

On 19-Aug-05, at 5:03 AM, Vijay Aswadhati wrote:

> Most of the code that I have seen for __gc is a bit different from the 
> use case
> I have. I understand the part of __gc function being a metamethod and 
> hence can
> only be set on the metatable.  But the __gc method will only be 
> invoked for
> fulluserdata and not for a regular table -- is that correct?

Yes, that's correct.

> Notice that Z_init() is called when the module gets loaded by Lua. Now 
> when the
> module is unloaded I HAVE to call Z_fini(). How do I do that. If I 
> don't there
> will be resource leaks in the 'Z' C module.

How would the module be unloaded?

> There is no userdata involved here just plain 'C' functions. So I 
> cannot fully
> comprehend the suggestion to use a fulluserdata.

You could create one and attach the __gc metamethod to it. Then you 
just have to make sure that the lifetime of the userdata is the same as 
the lifetime of the module. In fact, the expected approach would be to 
actually unload the module in this __gc metamethod, but as you say 
there are a host of issues with unloading modules:

> One way this can be done is to use DllMain for .DLL and _init/_fini 
> hooks for
> .SO; but in both Windows and *nix such a solution comes with a host of 
> other
> issues.
>
> Any suggestions? Am I the only one facing this problem?

I don't think that dynamic unloading is very common on most platforms. 
For one thing, it doesn't work very reliably. For another thing, it is 
hard to know when a module *can* be unloaded: you have to be very 
certain that no reference to anything in the module was left; not just 
C functions, but also static data, etc. Finally, the resources occupied 
by an unused but dynamically loaded module are not usually very 
precious (now that we're not trying to shoehorn programs into 32K of 
RAM -- I gather that you're not in one of those environments from your 
reference to Windows.)

> Would there be screaming if I suggest that luaopen_XXX be made 
> symmetrical in
> that as a convention if luaclose_XXX exists in the dynamically loaded 
> module
> then it would be called when a module is unloaded - I should add 
> 'somehow'.

Lua does not ever unload modules, so the "somehow" question here is 
pretty important :) Lua doesn't call luaopen_XXX automatically, either.