2012/4/2 Carsten Haitzler <ras...@rasterman.com>: > 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.
You think that it's better to do not unload the module than adding new API such as eina_module_resident. Actually, I want to use this new API in elementary map widget. If not use this API, loaded module list may be remained as static variables even if elm_map is deleted, also module is not unloaded. Next time, when map is added again, static variables (previously loaded modules) are checked and used again so as to do not load the module (if loaded, it can be memory leaks). Is this correct usage?? I think that eina_module can support this so as to other libraries do not care about static variables. Maybe, I am so lazy man. :) >> 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 > -- BRs, Kim. ------------------------------------------------------------------------------ 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
