Re: [E-devel] [EGIT] [core/efl] master 01/01: evas: Add configure option to disable cserve
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 Sverzut Barbieri -- Mobile: +55 (19) 9225-2202 Contact: http://www.gustavobarbieri.com.br/contact -- 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=60134071iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: evas: Add configure option to disable cserve
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=60135031iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: evas: Add configure option to disable cserve
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. -- Cedric BAIL -- 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=60135031iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: evas: Add configure option to disable cserve
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=60135031iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
