[Asterisk-Dev] Module unloading

Paul Cadach paul at odt.east.telecom.kz
Mon Jul 5 01:59:16 MST 2004


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.

> 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.).

> 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.

> 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.

> 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.


WBR,
Paul.





More information about the asterisk-dev mailing list