[Asterisk-Dev] Module unloading
Michael Sandee
ms at zeelandnet.nl
Mon Jul 5 00:07:18 MST 2004
Hi Paul,
Paul Cadach wrote:
>Hi,
>
>Michael Sandee wrote:
>
>
>>However it's a good thing that it will be fixed in the future...
>>
>>
>
>It could be fixed in very near future because it's very easy, but developers isn't agree to make non-critical changes
>until 1.0 will be released.
>
So... you agree with me here I presume...
>>Other than that you are pushing this into a discussion between atexit()
>>or unload_module()... which it isn't... I am pointing out that the
>>"documentation" is incorrect regarding the current implementation.
>>
>>
>
>unload_module() is very simple - just clean-up all stuff used by module (hangup all active calls, unregister cli/manager
>callbacks, close sockets, etc.).
>
I don't see the point you are making here. Ofcourse it is... the problem
I am talking about is that the module-framework isn't doing what it is
supposed to do (according to the documentation)... that is call
unload_module() on exit (whichever path of exit this is).
>>Which
>>is *very* annoying for module developers. All I wanted to do is raise
>>some attention on this subject so that we could see if it could be fixed
>>in the long term... and propose a short term sollution to module
>>developers (which already exists in existing * installations, in
>>contrary to your sollution).
>>
>>
>
>Providing atexit() interface and fixing all existing modules requires more work than fixing existing more-or-less
>working unload_module() interface.
>
Most modules don't specifically need an atexit() handler, since all they
do is free memory, which is freed by the system once the process ends
anyway. Although I agree it is ugly... it's been this way for ... 5
years?... so there is not a real rush to fix it for those modules. It
*is* needed however for modules that need it (do some magic on exit)...
such as res_musiconhold.so which already uses atexit()... and also the
module I wrote... and modules by some other people.
>>The atexit() changes are trivial to a module, as I explained in one of
>>the previous mails, so "overhead" is pretty much bullshit. Once the
>>module-framework has been fixed it can be changed back.
>>
>>
>
>Module developers needs to pay attention to track where register_atexit()/unregister_atexit() must be called, so just
>unload_module() is much simple solution.
>
It is better to do some work on their modules which makes it work with
existing Asterisk installations, then to wait for a fix which might not
appear in the coming 2 years... and that needs an Asterisk recompile to
a CVS HEAD version... but people seem to like living on the edge here.
Other than that... the register/unregister is *trivial* as I mentioned
in my first mail... you could use the code of your unload_module() as it
is...
>>Btw, why hasn't
>>your code been commited, if it was there for 0.5.0?
>>
>>
>
>Mostly because it was outdated when I published it. I'll try to talk with Mark about force cleaning shutdown/unload
>code, but I don't think this work will have very high priority in comparsion with fixing other existing and new bugs in
>current Asterisk's versions (-HEAD and -STABLE) to prepare 1.0 version out.
>
Again... it has no priority for you, it does have priority for module
developers... some 3rd party modules didn't work like they should... and
that was because of *faulty documentation*. So my original standpoint is
still there... documentation is incorrect because it is not implemented
and current modules should use ast_register_atexit() when needed. And if
I read your last comment correctly you should advise module developers
to use atexit() because it will most likely not get fixed anytime soon.
Michael
More information about the asterisk-dev
mailing list