Ok, I haven't undestood much (sorry, I'm not a dev). But you guys seem to know what you are doing (duh!)
anyway, thanks for your answers =D 2011/5/14 Carsten Haitzler <ras...@rasterman.com> > 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 > > -- Wido ------------------------------------------------------------------------------ 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-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
