On Tue, 15 Oct 2013 10:20:21 +0900 Cedric BAIL <cedric.b...@free.fr> said:
> On Tue, Oct 15, 2013 at 9:13 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > 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). :) > > Yes, sure, but right now nobody is using it except JP and he has a lot > of patch that need to be included in master (That should be done > really soon). Also the code is yet not refactorized and not portable, > so there is a long way before we can consider that our ONLY path. In > fact right now, I would advocate for it to be optional in efl 1.8 if > we are to release it in the coming month. it doesn't mean we have to ADD in stuff to allow it not to be built. building it doesn't hurt other than some disk space and a bit of extra code support and we are moving that way anyway. :) -- ------------- 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
