On Wed, 19 Apr 2017 09:42:50 -0700 Cedric BAIL <[email protected]> said:
> On Tue, Apr 18, 2017 at 11:02 PM, Jean-Philippe André <[email protected]> > wrote: > > On 19 April 2017 at 14:53, Vincent Torri <[email protected]> wrote: > >> now that evas depends on ecore, should cserve2 be ported to ecore ? > > > > If anyone wants to do it, why not. > > I guess it would simplify the code. > > > cserve2 isn't used because it still has issues, especially after one side > > crashes (server crash in particular). > > Also the performance results were rather worse than local-only image loads, > > while the original premise of cserve was to improve the perfs. > > As a tradeof, it did help for memory use... when everyone was using > the same theme. There is still potential for improvement, but a lot of > more additional work is actually necessary and depending on your use > case, it may or may not help. actually the absolute nicest thing about cserve was that loading was farmed off to slave processes. this meant any crashes in a loader at most took down some slave process. the whole image loading subsystem though needs a rewrite/redesign. we can use actual loader code we have, but all the stuff above it needs a re-do. my thoughts are that we should really externalize the loaders via some slave process. now to do this portably and keep performance high is the trick. on unix i'd simply vote for allocating shared memory segments in the slave, then fd passing them back to the parent via a socketpair. in fact just using memfd if possible. this is not so easy for windows. well i don't know if it's even possible. also any rewrite would totally move all the loader core code to a slave thread with anyone requesting work from it to do it via "ipc" to that thread. does anyone have any insight on windows here?can we write some portability wrappers maybe in eina/ecore to make this easier? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
