[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