2010/9/15 Robert Norris <rw_nor...@hotmail.com>: > 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/
