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.
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. 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. 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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
