> > 2010/9/15 Robert Norris : >> I would quite like the only known repeatable crash >> https://sourceforge.net/tracker/?func=detail&aid=3009431&group_id=83870&atid=570954 >> about the map auto download and GPS auto following conflict to be solved >> too. >> I posted a bit about this on this mailing list a while ago. > > I only retrieve the comment you made on the ticket. If there is any > other message about this topic, can you resent or send a URL to the > archive?
My thoughts at that time, would be that a more involved solution would be needed to get the threading to work properly. However I my efforts to make the DEM loading work in the background (using the background thread pool stuff), it also calls update draw had the same crash as the maps/GPS conflict. I realised the gtk_threads_enter/leave solved the issue for my DEM method and also should solve the GPS drawing crash. [Since that's how the current map drawing works when called from another thread]. NB DEM layer background loading is a 1.0+ change. It's in my local git repo. >> I believe the best way would be a mutex in the struct _VikViewport which >> could then control the access to gdk_draw_pixbuf inside the >> vik_viewport_draw_pixbuf function. >> Maybe I'll do that too.... > > I spend some time to look at multithread aspect of viking. My limited > skills (in viking internals and GTK/thread model) make me suspicious > about many code part. > > I understood that Gtk signals are thread-safe as they are "executed" > in the main thread (the one running mainloop). > So, I think most of the background.c code can be refactored to use > signals instead of gtk lock. > Why? Currently, all downloader threads regularly locks mainthread (and > other threads) simply to refresh the progress view. > IMHO, some signals can be much better as the UI aspect will be managed > by a single thread: the main one. This is mostly possible here because > information to exchange between downloader and UI is really simple. I don't know, it mostly works so why bother changing it? A good reference: http://library.gnome.org/devel/gtk-faq/stable/x481.html ATM downloader threads naturally run out side of the GTK lock, thus 'signals' from these threads in glib need to call gdk_threads_enter() before doing gtk stuff. > Looking at the code, I do not understood the meaning of the "trigger" > concept (between viklayer, vikwindow and vikviewport). Furthermore, I > have the feeling that it is not really thread-safe concept. But as I > don't understand, I can't be sure. > No idea either - the half draw trigger thing is also mysterious. PS Has anyone heard from Quy Tonthat, Alex Foobarian or Evan Battaglia / what happened to them? ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
