Re: [Viking-devel] Multithread (Was: Plans for 1.0)
2010/10/7 Robert Norris : > >> >> 2010/9/15 Robert Norris : >>> 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? I have the feeling that we can improve both UI reactivness and tile downloading. > 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. What I understood is that gobject-signal is treated by mainloop-thread. I also understood that the callback should use gdk_threads_enter/leave, but only the main thread will be locked, not download threads. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- 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/
Re: [Viking-devel] Multithread (Was: Plans for 1.0)
> > 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/
[Viking-devel] Multithread (Was: Plans for 1.0)
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? > 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. 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. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
