On Sat, 14 May 2011 21:09:25 -0300 Wido <wido...@gmail.com> said: > >> General Users = safety, if any of these loaders crash or hung, the main > >> program/process will not crash. > > > > actually... hanging can be a problem as evas opens a pipe and waits on > blocking > > input. it has no timeout, so if it hangs, evas using process will too. you > can > > just kill the external loader process pid and the app will unhang (and > then > > load fails) - so its recoverable, and probably a sign to uninstall that > > specific external loader and file a bug. :) > > wait....what?? no timeout for an external pipe?? isn't that a design flaw?
not really - the loader uses popen() as opposed to writing 100's of lines of code to fork + exec and handle the pipe itself with a select etc. > you're just saying it, if the external process hungs, evas hungs. Who do you > think users will blame? remove the loader. as i mentioned. > I know, you're probably going to say that an external loader could take a > lot of time (i'm imaging a 70MB pdf with lots of pictures and stuff). > > But that's not a reason to not have a timeout, at least set a long timeout, > like 60 or 90 secs. And after that time, also try to kill the piped PID > (though I'm not sure if it's possible to do that) if evas hangs even for 10 secs... people will still blame evas. you either have a very short timeout ands then rule out being able to load "very slow/complex stuff" or you have a long one and regardless they will jump up and down and complain. the solution STILL is the same -> remove the loader that is to blame (easy to spot in your process list though). evas's 2 stage load has the ability to NOT block when loading the DATA (preload with thread) so that won't block the app if loader blocks on a slow "rendering of a ppt" for example or rendering a complex pdf (svg suffers the same issue fyi). the problem is that the "head" stage is never async. its always sync. THAT should be improved/fixed in evas. allow it to become async. > Or I'm saying stupid things again and I have to go back to my cave? > > 2011/5/13 Carsten Haitzler <ras...@rasterman.com> > > > On Fri, 13 May 2011 15:47:20 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > > On Fri, May 13, 2011 at 2:50 PM, Wido <wido...@gmail.com> wrote: > > > > > > > Excelent!!! but what is the first impact for non-developers users? > > > > > > > > > > End Users = more image formats supported, like gimp (xcf) and pdf. > > > > > > Proprietary Users = you can use Evas (declared BSD, really LGPL due Eina) > > in > > > your proprietary application and use GPL library loaders as they're out > > of > > > process, thus no license linkage problems. > > > > well not really. evas doesn't become lgpl because it links to an lgpl lib > > :) > > but the point is still right - apps are unaffected by license of external > > generic loaders, so we can expand the # of formats evas can load in the > > "gpl" > > direction AND in the "it's complex and/or unstable" direction (html, > > ppt/doc/xls etc. loaders and so on). it basically makes it all possible > > (but as > > you noted - there is a cost). > > > > > General Users = safety, if any of these loaders crash or hung, the main > > > program/process will not crash. > > > > actually... hanging can be a problem as evas opens a pipe and waits on > > blocking > > input. it has no timeout, so if it hangs, evas using process will too. you > > can > > just kill the external loader process pid and the app will unhang (and then > > load fails) - so its recoverable, and probably a sign to uninstall that > > specific external loader and file a bug. :) > > > > > Problems: this is not as fast as a native loader, so we'll not move every > > > (if any!) loader to be external. > > > > yeah. that's its major Achilles heel. it has a speed and overhead penalty. > > > > > > > > -- > > > Gustavo Sverzut Barbieri > > > http://profusion.mobi embedded systems > > > -------------------------------------- > > > MSN: barbi...@gmail.com > > > Skype: gsbarbieri > > > Mobile: +55 (19) 9225-2202 > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > -- > Wido -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
