On Mon, 6 Jan 2014 23:09:59 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Mon, Jan 6, 2014 at 10:53 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Mon, 6 Jan 2014 15:47:07 -0200 Gustavo Sverzut Barbieri > > <barbi...@gmail.com> said: > > > >> On Mon, Jan 6, 2014 at 1:16 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > raster pushed a commit to branch master. > >> > > >> > http://git.enlightenment.org/core/efl.git/commit/?id=6f685d760851e1ccf33017b2a749008475e2ac7c > >> > > >> > commit 6f685d760851e1ccf33017b2a749008475e2ac7c > >> > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > >> > Date: Mon Jan 6 12:16:36 2014 +0900 > >> > > >> > fixme notes - fixme: many instances of module loading that bloat our > >> > mem > >> > --- > >> > src/lib/ecore/ecore.c | 5 +++++ > >> > src/lib/ecore_imf/ecore_imf_module.c | 3 +++ > >> > src/lib/eeze/eeze_sensor.c | 3 +++ > >> > src/lib/eina/eina_mempool.c | 3 +++ > >> > src/lib/ethumb/ethumb.c | 5 +++++ > >> > 5 files changed, 19 insertions(+) > >> > > >> > diff --git a/src/lib/ecore/ecore.c b/src/lib/ecore/ecore.c > >> > index 5870206..3477aca 100644 > >> > --- a/src/lib/ecore/ecore.c > >> > +++ b/src/lib/ecore/ecore.c > >> > @@ -183,6 +183,11 @@ ecore_system_modules_load(void) > >> > eina_prefix_lib_get(_ecore_pfx)); > >> > module_list = eina_module_arch_list_get(module_list, buf, > >> > MODULE_ARCH); > >> > > >> > + // XXX: MODFIX: do not list ALL modules and load them ALL! this is > >> > + // just polluting memory pages and I/O with modules and code that > >> > + // is then never used. detetc the module we need to use them use > >> > + // that. if anything load each module, have it do a detect and if > >> > + // it fails UNLOAD and try the next one. > >> > eina_module_list_load(module_list); > >> > } > >> > >> Are you sure what you're talking about? we always use all installed > >> system modules, they are in their own directory for that reason. > > > > you use tizen, upower AND systemd at the same time? both systemd and tizen > > handle ECORE_EVENT_LOCALE_CHANGED events. both upower and tizen handle > > ecore_power_state_set(). > > then you shouldn't install both modules. I guess for tizen you just > install their version until they get rid of such nonsense. > > > > even if there is no systemd daemon (and dbus service) or upower service... > > or vconf database is missing (libs there, data is not), we load ALL modules > > and init ALL modules and we KEEP all modules we loaded, even if their own > > inits failed. > > you just know if they failed if you load them, as we don't dlclose() > in efl, what could we do? open an exception here and dlclose if > failed? that's what i'm thinking. the "don't dlclose" is a general solution to callbacks still being registered and used. since these are fairly small modules with very limited scope and they do clean up their callbacks, it probably is safe. what is more likely needed is some kind of system configuration indicating which to use at runtime. possibly/probably even have simplified detection code in ecore that then chooses the right module(s) to load. > > so we have conflicting domain control above since multiple modules are > > installed (no decision on which one wins or loses), and failed inits keep > > the module loaded though - forever. :) > > as above, how do you plan to unload here? we don't do it for the > always mentioned reason (something may still refer to unmapped > memory). > > as for decision on priority, I don't like the idea of adding such > complexity as it will be on a case by case for system modules. You may > have a single module that provides everything (ie: Tizen) while others > are provided by individual pieces (systemd, upower, ...). I guess > sensors will be the same. Then it's simper to just delegate that to > packagers, like in ArchLinux one could suggest install "ecore-systemd" > if systemd is installed, or in Gentoo use a flag. Regular distros such > as Ubuntu/Fedora force this in their high-level "desktop" packages, > depending on what they recommend for their default out-of-the-box > experience (if you dislike it you can uninstall stuff but you lose the > high-level metapackage. > > In places where it's simpler to state so, such as IMF, we already have > an environment variable and could use it, defining a policy when > nothing is set (ie: load one module at time and stop after the first > loads fine). same for ecore. in general we have this pattern throughout efl and it's a bad pattern. it needs fixing. > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (19) 9225-2202 > Contact: http://www.gustavobarbieri.com.br/contact > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > 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 ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel