On Thu, 5 Apr 2012 14:56:15 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> On Thu, Apr 5, 2012 at 6:24 AM, David Seikel <[email protected]> wrote: > > On Thu, 5 Apr 2012 19:00:15 +1000 David Seikel <[email protected]> > > wrote: > > > >> On Thu, 5 Apr 2012 10:17:42 +0200 Cedric BAIL <[email protected]> > >> wrote: > >> > >> > On Thu, Apr 5, 2012 at 1:29 AM, Gustavo Sverzut Barbieri > >> > <[email protected]> wrote: > >> > > On Wed, Apr 4, 2012 at 7:23 PM, Vincent Torri > >> > > <[email protected]> wrote: > >> > >> On Wed, Apr 4, 2012 at 7:34 PM, Rafael Antognolli > >> > >> <[email protected]> wrote: > >> > >> Some questions : > >> > >> * what about the Coyote and ps3 arch ? > >> > > > >> > > Same as cserve, it will not be supported due the lack of > >> > > multi-process support. > >> > > >> > There is still many non multi-process system out there. I have been > >> > thinking all this night how to make this work. At least they all > >> > have some thread support. So maybe we could have a fallback mode > >> > that instead of making cserve a standalone process, it will become > >> > a thread task. In that case, it does have some implication, how to > >> > handle the main loop ? We should make it possible to run multiple > >> > ecore main loop or have a light main loop support. I don't know > >> > yet. The other question will be, where should we launch this thread > >> > task, in evas ? Then we have a build dependency in it. Or in > >> > Elementary, but it sounds more like a work around. So I really > >> > don't know. > >> > > >> > This is just throwing idea in the air, just in case someone get a > >> > brilliant one and we can fix this use case. If not, that would be > >> > sad, but we should have some time to find a proper solution. > >> > > >> > >> * will cserve2 be optional like cserve ? > >> > > > >> > > To start, yes. If it proves mature and to work well, Raster plans > >> > > to make it the default mode. If it goes well, it may be the only > >> > > way. As you can expect, there is a long road to it, including: > >> > > - port to other systems (BSD, Windows...) > >> > > - figure out what to do for too-different archs such as > >> > > single-process native PS3. > >> > > > >> > > For the last point I have not many details. As far as I understand > >> > > the lack of multiprocess in PS3 is an implementation issue, that > >> > > could be added later? (KaKaRoTo voice in!). > >> > > >> > They have no multiprocess, but they do have some kind of thread > >> > support. So there is a way to support this feature at least in > >> > theory, we just need to think about how. > >> > >> PS3 has a hyperthreaded CPU. Not counting the CELL SPUs, since code > >> for those has to be written specifically for them. > > > > On the other hand, my tiny embedded project uses a single 486 core. won't matter. you have a linux kernel. it can schedule threads and processes for you. hell it can PRIORITISE processes nicely. you can drop the priority (nice value) of the daemon to ensure it almost entirely ONLY uses idle cycles, actually IMPROVING responsiveness as decode/io is only done when there are spare cycles. man sched_setscheduler() and look at SCHED_IDLE. an added bonus is also security and stability. no longer can an image loading lib crash your app. it will just crash that loader slave. you lose that image, not your whole world. :) > We appreciate if you can check the impact on it. > > Of course it depends on the use cases, if there is a single process > doing UI and it's loading just safe data (ie: edje/eet), then there is > no gain... but penalty shouldn't be o heavy. with some prioritisation options it should actually be better ultimately. :) > But if there are multiple process as the normal case, then the > benefits should exist on memory saving. > > Another clear benefit is dealing with user-media, such as mmc/sd with > huge JPEG, or broken filesytems... The processes shouldn't crash or > hang anymore. aye squiddie! :) > Last but not least, a benefit we foresee is avoiding blocking the > application main loop. The end goal is to have cserve2 to do > speculative preload. But even without it, when we go further with the > project, it is expected that the IO an CPU used to load and decode the > image, is on the secondary processes and the main application can work > without blocking user code. This will be done by a multi-threaded > render phase (one thread to calculate changes, send to another thread > to request resource load, yet another to execute the drawing commands > -- drop frames between these as required). > > Anyway, likely impossible to make everyone super-happy, but our goal, > including Raster, is to focus on the biggest bucket that is desktop > and high-end embedded systems. yeah. frankly our userbase is this. also the developerbase - the majority. technically this CAN work on windows as it has all the facilities needed. design-wise its ok. it just needs glue. it can work on all unixes. it can work on osx, android and even wince (though the 32 process limit may become an issue if we don't keep daemon down to 1 instance and # of decoder slaves down to 1 or 2). this should work on ps3 too - but via threading emulation so u dont get the stability/security improvements. but it should be workable. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
