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?


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

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

Reply via email to