On Sat, 31 Mar 2012 21:33:50 +0900 Bluezery <ohpo...@gmail.com> said:
> 2012/3/30 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>: > > On Fri, Mar 30, 2012 at 3:43 AM, Bluezery <ohpo...@gmail.com> wrote: > >> Hello, > >> > >> I want to add new eina_module_resident() API in eina_modules. > >> This function makes the module never be unloaded before process is closed. > >> This is needed in which case a module should not be closed. > >> For example, if a module uses static GObject, closing and reopening > >> it cause crashes. > >> Because a module can be made by other opensource or proprietary code, > >> this API is needed. > > > > Wasn't a common sense that dynamically loaded modules should be never > > unload? I recall raster disabling the actual dlclose(), if not in > > Eina, something in e_modules... It's too dangerous, and is it worth? > > You mean that forbidding module unload is a common sense?? (Sorry for > my understanding English.) correct. the core problem is that modules often create objects. these objects are held by tings like evas - or other subsystems. these objects often refer to callbacks from a module. if you unload a module, even *IF* it deletes objects, reference counting may mean they have to stay around for a while. they now have functions pointing off into memory that no longer exists (unmapped) and all sorts of un-fun things happen. from segvs to randomly jumping into code that isn't a function at all (unload module, load new one, recycles same memory space. new code at same address. BOOM!). with GREAT care can you avoid this by removing all function pointers/callbacks (nulling them out - assuming the code handles them being null at all and doesn't assume they are minimum basic requirements). even if you can do this t most, some funcs are basic parts of object infra and thus you cant unload until all objects cease referring to the funcs from a module. in general you are just better off not unloading and relying on the next time you start the process simply meaning you wont load the module you disabled last time. > I agree with that. It's too dangerous to dlclose(). > But, dlclose() is not disabled in eina_module currently. So I want to > add API for giving rights to disable this for end-users. no - it's there as it leaves it up the the user of eina_module as to if its safe to close a module. 98% of the time it is not. but it *IS* possible to do so, if you wish. > I looked around the e_module. And I found that e_module does not > eina_module and use dlopen() directly. Also it do not use dlclose() > except error. e modules predate eina_module by several years. thus its still the old code it has always had. > > As a note, kernel developers condemn module unloading, saying it's > > just a module developer feature and should never be used by end-users > > (although we all do to work around buggy kernel modules such as > > broadcom's proprietary wifi). > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -------------------------------------- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > BRs, > Kim. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
