Wassssuuuuuuuuuuuuuuuuuuup 2012/4/12 Carsten Haitzler <[email protected]>: > On Wed, 4 Apr 2012 11:52:29 -0300 Rafael Antognolli > <[email protected]> > said: > > i been lookin' at ur codez yo. :) > > general question... what's up with image saves? :) (makes sense to have them > salved off but as a direct child of the process not of the resource loader?) >
wat About the image savers, we have no plans to put that in the server, but keep them in Evas as they stand. Having the savers in cserve would add a significant overhead for no benefit. > so partly i see old code moved/copied in from core loader infra. ok - cool. > > what is this cserve2_timeout_cb_set() every 3000ms? do we really need to be > spinning every 3000ms killing slaves? just timeout once, kill and only queue > timeout if we start slaves again? that's what it looks like. That's on the TODO. The idea is not only to avoid the unnecessary timeout, but also keep slaves around until there are no more requests. Right now if the timeout triggers, slaves will die and be immediately restarted if there are still pending tasks. Focus, however, is on getting Elementary and E17 to work flawlessly with cserve2 before we tackle those issues. > > evas_cserve2_cache.c i think could be broken up into actual JUST cache handler > (in memory has+LRU list) file watching and some message and protocol handling > files. > A nice idea, it's turning into a beast already. > i see that you havent come up with a good/proper socket naming scheme yet... > /tmp/cserve2.socket... yay! :) At least it has a name, the first version we did was recursively opening every file on the system until one sent a valid response, then it was assumed to be the cserve socket. Security wise it was wonderful, as no one had any way of knowing what name or where the socket was to attempt any hack, but when opening an image took 3 hours we decided to go with a more conservative method. > > other than that - the evas_cserve2_slave.c could do with a little more > abstracting so it COULD run as a thread inside of cserve (ps3?) and > evas_cserve2_main.c. specifically the main() funcs could be one level up from > their content so pthread_create() can call the children if needed later. > Yep, the slave was supposed to be a simple test to make sure things were working fine, then laziness won and it ended up being the real thing. As it stands, it's not even as Windows friendly as I wanted originally, but it will be there by the time it hits SVN. As said above, getting the big picture to work as expected is the priority. > that's it for now. feedback done :) > Thanks, there'll be more to look at and test soon enough. > >> Hello people, >> >> As some people know, ProFUSION is also working on Evas and making some >> changes that should make it even faster. >> >> Currently we are working on the images cache server, and it should be >> similar to the previous cserve, but with a more asynchronous API. It >> also has some fundamental changes, like having a pool of loaders where >> each of them run on a different process. >> >> The main idea is that the client can request the images needed as soon >> as a file_set is done, but don't block waiting for them to load. Once >> Evas really needs the image data, it will finally block to get this >> data, and should return almost immediately if it was already loaded. >> >> Some tweaks still must be done on the current code, some cleanup, and >> even some documentation, but the core is already there. A new internal >> cache was also done for Evas, very similar to the previous one but >> with some more direct calls to the server and some shorter code paths. >> >> The code can be seen here: >> http://git.profusion.mobi/cgit.cgi/antognolli/evas-cserve2/ (branch cserve2) >> >> Any comments are welcome! >> -- >> Rafael Antognolli >> ProFUSION embedded systems >> http://profusion.mobi >> >> ------------------------------------------------------------------------------ >> 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 >> > > > -- > ------------- 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 ------------------------------------------------------------------------------ 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
