[Asterisk-Dev] Module unloading

[Michael Sandee]

Hi Paul,

I still don't see how this is a sollution which can be used by module 
developers in short term... This is the whole point of the problem... 
ofcourse it can be fixed in the core... but that doesn't help anyone at 
this point, it will also need good testing, some icky stuff will happen. 
However it's a good thing that it will be fixed in the future...

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

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. Btw, why hasn't 
your code been commited, if it was there for 0.5.0?

Michael

Paul Cadach wrote:

>Hi,
>
>Michael Sandee wrote:
>  
>
>>1) Asterisk 1.2 could be years away... planned fixes don't fix my problem.
>>    
>>
>
>We could force unload cleanup before 1.2...
>
>  
>
>>2) You can fix it at Asterisk's core... you think... but this might
>>(will) break modules, and you get a *lot* higher chance of lockups. I
>>think it is why it isn't implemented yet. Which is ok...
>>    
>>
>
>I'd done proper shutdown with clean module unloading at Asterisk-0.5.0 tree. There was not so hard to do so (one new
>procedure to unload ALL modules, some fixes for shutdown process, and some fixes for unload_module() procedures to
>cleanup all used resources where some things are missed).
>
>  
>
>>Several people actually already told me they had it wrong in their
>>modules, apart from me... so that means something is wrong.
>>    
>>
>
>atexit() technique, may be, is more clean to understand, but will provide some additional overhead for module's core
>work, so IMHO better is to cleanup unloading code instead of making some look-a-like scheme with atexit().
>
>
>WBR,
>Paul.
>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>  
>