Hello!
Petr Vaněk has written on Wednesday, 20 November, at 9:00:
>I'd play a devil's advocate here.
>What's real profit of this potential move? (except "yeah, it looks cool")
They said - few MB of memory (well, in the best case, only if image
cache is cleared very often and fast) and also few milliseconds (time of
launching few PIDs) is the profit.
>"We should just make sure modules never crash! ;-)" - it speaks for
>itself = impossible.
After all the discussion I've read that restarting all the processes
is a mandatory thing (because they crash now and then) I can only laught
over "never crash". And yes, that will bring the problem of state saving
of all the components after each change (window resize, menu navigation,
etc.) wouldn't that create a too big impact on disk and therefore on
performance? And yes, state change is mandatory in library approach, just
a simple use-case: you type a program name in "Run..." dialog and your
screensaver was crashed. In case of standalone program that is not any
problem, it will be restarted, but in case of library you _should_ save
any letter typed in and enter them again after restart-of-all. :D
>Will it make development easier? A standalone app can be started,
>killed, run under gdb/valgrind (yes, I do it time by time). How can I
>examine eg. panel library with valgrind in this lib-approach? Output
>will be obfuscated by false positives from desktop etc...
It will make development a hell I believe. ;)
>that's only what I can think about in few minutes... but it does not
>mean I'm strictly against it. I'm just not a friend of "rapturous"
>changes ;)
I'm second on that. Since I earn my life money by making software
(yep, I am a programmer), I can assure you - the worst way to make any
good software is to make it "all-in-one". Well, there are quite few
workarounds to make it (don't use shared libs but use dlopen() with
internal debug and crash handlers that will backtrace and unload the
crashed code, which involves also creating some envelopes to isolate
those dinamically loadable libraries), but that will make it too much
complex and inconvenient to develop. And despite the fact new PID takes
more resources I use execv() instead of pthread_create() for external
functionality when reliability is required. Well, if you create new
Windows, then make the DE a single application might be a choice, but
otherwise I'm highly against it. ;)
Cheers!
Andriy.
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
