Raster, On Sat, Aug 31, 2013 at 1:31 AM, Carsten Haitzler <[email protected]> wrote: > On Fri, 30 Aug 2013 10:58:55 -0300 Ulisses Furquim <[email protected]> said: > >> Raster, >> >> On Fri, Aug 30, 2013 at 5:11 AM, Carsten Haitzler <[email protected]> >> wrote: >> > On Thu, 29 Aug 2013 10:26:50 -0300 Ulisses Furquim <[email protected]> >> > said: >> > >> >> Raster, >> >> >> >> On Thu, Aug 29, 2013 at 9:18 AM, Carsten Haitzler - Enlightenment Git >> >> <[email protected]> wrote: >> >> > raster pushed a commit to branch master. >> >> > >> >> > commit 42a46214c4f9b35c0e1f5a84c56ea76ba2235eae >> >> > Author: Carsten Haitzler (Rasterman) <[email protected]> >> >> > Date: Thu Aug 29 21:18:04 2013 +0900 >> >> > >> >> > other async render issue - sync ALL rendering canvases, not just one >> >> > --- >> >> > src/lib/evas/canvas/evas_render.c | 2 ++ >> >> > src/lib/evas/common/evas_thread_render.c | 21 ++++++++++++++++++++- >> >> > src/lib/evas/include/evas_common_private.h | 4 +++- >> >> > 3 files changed, 25 insertions(+), 2 deletions(-) >> >> > >> >> > diff --git a/src/lib/evas/canvas/evas_render.c >> >> > b/src/lib/evas/canvas/evas_render.c index b04d606..4fbe9e2 100644 >> >> > --- a/src/lib/evas/canvas/evas_render.c >> >> > +++ b/src/lib/evas/canvas/evas_render.c >> >> > @@ -2235,6 +2235,7 @@ _canvas_render_dump(Eo *eo_e EINA_UNUSED, void >> >> > *_pd, va_list *list EINA_UNUSED) Evas_Public_Data *e = _pd; >> >> > Evas_Layer *lay; >> >> > >> >> > + evas_thread_queue_block(); >> >> > evas_render_rendering_wait(e); >> >> > evas_cache_async_freeze(); >> >> >> >> This might deadlock. If the queue is no empty and we have there the >> >> commands for e then we'll wait forever in _rendering_wait() in the >> >> main thread and the render thread will sleep forever trying to acquire >> >> the evas_thread_block_lock. Right? >> > >> > fixed. i didnt notice evas->rendering was set in evas_render as opposed to >> > the rendering handle in the async thread. :) >> >> Well, yes, your change solves the deadlock. But I want to know what >> you want, really. Do you want a call to sync all canvases? This lock >> is not doing that. We'd need to wait all canvases rendering flags to >> be set to false and then return. This way we wouldn't have any pending >> commands in the render thread. > > in doing the async rendering the code to dump data was totally disabled. > image data with refcounts > 0 were now never dumped. why? why fix for "i have > a > background thread still using that data to render while my mainloop is > dumping". the "wait for evas to finish" waits for the GIVEN evas to finish... > ONLY that one. but the background async renderer may march on to the NEXT > canvas wanting a render in the queue and it doesn't wait for that. it > continues > and we just now dumped images from memory it needs. as the load data is done > before the async renderer begins and it assumes data is there and ready, so > this block basically forces the dump cal to wait for the async renderer to > finish going through ALL queued rendering so far - not just once canvas, but > all of them, since its a mutex lock around that block of code. this then > allows > all image data to be dumped from memory (even refcount > 0) which is what the > original intent and code was doing. now it's safe and any new renders come > from > the mainloop afte the dump and they can/will re-load data from files if needed > for the async renderer to work properly. no - it's not pretty, but it fixed > the > dump functionality.
This problem is now hard to reproduce but we still have a race with your fix. That lock doesn't guarantee what you want. If you happen to acquire the lock in the main thread just before the render thread tries to acquire it then after you clean up and release the lock the render thread will acquire it and we have a problem. Even though still difficult to happen this race is more prone to happen if the canvas you passed to _rendering_wait() is not rendering at that moment. Moreover, I don't like this lock in the render thread and being able to block/unblock it. It's a deadlock wanting to happen. I'll see what I can do here but we need a proper sync all canvases function. It should be simple if we can just wait on the rendering flags for all canvases. -- Ulisses ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
