On Mon, 14 Oct 2013 12:24:41 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Sun, Oct 13, 2013 at 11:13 PM, Jean-Philippe Andre > <jp.an...@samsung.com> wrote: > > jpeg pushed a commit to branch master. > > > > http://git.enlightenment.org/core/efl.git/commit/?id=b1437273890058ce9e84f5efd3195f8834d0f9c0 > > > > commit b1437273890058ce9e84f5efd3195f8834d0f9c0 > > Author: Jean-Philippe Andre <jp.an...@samsung.com> > > Date: Mon Oct 14 10:32:16 2013 +0900 > > > > evas: Add configure option to disable cserve > > > > Some people might want to disable cserve2 at build time to > > generate smaller packages. > > wasn't the plan to disable non-cserve2 case and just have it as the > only option, making sure it works and so on? > > this go completely in the other direction... we used to have this > option, removed on purpose gustavo is right. we have too many paths of execution in efl in general - and unless it's onby default they basically don't get tested. the entire image loading etc. stuff is better served in cserve, one of the big reasons being memory efficiency (we use 3rd party libs like libpng, libjpeg, libtiff etc. a lot) and these libs come with lots of rw pages on their own, and thus bloat out the memory of every process once they touch such a file format. the loader binary slaves for cserve is in fact a great idea. they can be killed off after inactivity and cycle. but even better, they can CRASH and not take your app down. this is a major win. loading of data is one of the major vectors for attack security-wise and where if we have a bug, it can cause progrqms to become vulnerable to attacks via "show this jpeg" (if your app is an email client for example). keeping the attack surface small is a good thing. but it also helps out for all the mmap io we do. an mmaped file will cause a sigbus when you hit an io error. we patched over that with eina but its rather evil and eventually will fill memory with zero page turds. the above cycling cleans that out. so cserve is better for more than just sharing. and to ensure our codebase is SIMPLER... we want to move to the path of cserve being the ONLY path. it also opens up future possibilities if we have a daemon "manager/broker" always there. (hell - we could move RENDERING out-of-process... ok i can't think of a really viable reason why right now, but it's just to illustrate). :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
