Re: How to use Quarks?
hi, Patrick Braga wrote: > I've just begun learning GLib, and I came across Quarks. The > documentation describes them as "association between strings and integer > identifiers. Given either the stringo or the GQuark identifier it is > possible to retrieve the other." > > This seems really useful and all, but I have no idea when this could be > applied. I don't necessarily want code examples, just something like "if > you want to do this then you could use quarks to..." If you use a hashtable with strings as keys, a lookup on the hashtable would need to compare the strings to find the entry. In some situations you can store the key-strings in objects and in such a situation you better store the quarks and use the quarks as keys in the hashtable. Then the lookup only compares integers. Stefan > > Thanks! > > Patrick Braga > http://theunixgeek.blogspot.com > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: struggling with the non-recursive gdk_threads_enter
Alexander Larsson wrote: On Tue, 2008-12-30 at 21:47 -0500, Yu Feng wrote: Dear Devels: I am having troubles because the GMutex used gdk_threads_enter/leave can be non-recursive. IMHO that is a Gtk+ bug. When loading the modules from GTK_MODULE it should take the Gdk lock in order to provide the same behaviour in both cases. The way its currently set up means its impossible to get module loadind gdk-thread-safe in all cases. ... and IMHO the whole locking scheme of gtk is flawed. The future belongs to multi-cores, so we must expect multi-threading to become a much more popular thing. What I did to work around the issue, was add a couple of lines like: pthread_mutexattr_t gdk_lock_attr; pthread_mutexattr_init(&gdk_lock_attr); pthread_mutexattr_settype(&gdk_lock_attr, PTHREAD_MUTEX_RECURSIVE); pthread_mutex_init(&gdk_lock, &gdk_lock_attr); pthread_mutexattr_destroy(&gdk_lock_attr); gdk_threads_set_lock_functions(lock_gdk_lock, lock_gdk_release); but please be aware that some high-level gtk calls (dialogs), will expect to implicitly be able to unlock with a single call, and this must be handled in lock_gdk_lock() and lock_gdk_release() otherwise your app will hang. Now I know that some will argue that using all these cumbersome "add_whatever_handler()", will make for much cleaner code and such, but that just isn't good enough IMO - it makes cluttered code. I agree that many scenarios are best handled by a model/view/ctrl setup, but different people have different styles, and an elitist "there's only one right way to do it" is too black and white. br Nikolaj ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: struggling with the non-recursive gdk_threads_enter
On Tue, 2008-12-30 at 21:47 -0500, Yu Feng wrote: > Dear Devels: > > I am having troubles because the GMutex used gdk_threads_enter/leave can > be non-recursive. > > I have a piece of code (g_module_check_init) to either be called from an > event dispatched by GDK(if the module is loaded via GtkSettings) or be > called directly without entering the GDK critical section(if the module > is loaded via GTK_MODULE). > > The code need to be protected so that its execution is not interrupted > by GDK activities in other threads. How can I do this without a > recursive gdk critical section? IMHO that is a Gtk+ bug. When loading the modules from GTK_MODULE it should take the Gdk lock in order to provide the same behaviour in both cases. The way its currently set up means its impossible to get module loadind gdk-thread-safe in all cases. Its not really possible to drop the lock in the other case, so the only solution is to take the lock in this case. Its also in line with general Gtk+ behaviour to automatically have the gdk lock held when calling out to external code. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: struggling with the non-recursive gdk_threads_enter
Hi Friends, Thanks for the hint. I don't have the luxury to override the gdk locking functions since I am writing a plugin module for arbitrary applications; the application may also want to override the locking functions. This is the solution I came up with: in gtk_module_init, I defer the library init with a GIdle callback at G_PRIORITY_HIGH. Then I am able to use GDK_THREADS_ENTER/GDK_THREADS_LEAVE to protect my code, since the GIdle callback is invoked by the main loop, where the gdk mutex is released. This means when the library is initialized the state of the application differs from when the module is actually loaded. But it works for my module since the init code doesn't depend on the state of the application. Regards, Yu On Sun, 2009-01-04 at 13:30 +0100, Nikolaj Thygesen wrote: > Alexander Larsson wrote: > > On Tue, 2008-12-30 at 21:47 -0500, Yu Feng wrote: > > > >> Dear Devels: > >> > >> I am having troubles because the GMutex used gdk_threads_enter/leave can > >> be non-recursive. > >> > >> > > IMHO that is a Gtk+ bug. When loading the modules from GTK_MODULE it > > should take the Gdk lock in order to provide the same behaviour in both > > cases. The way its currently set up means its impossible to get module > > loadind gdk-thread-safe in all cases. > > > > > ... and IMHO the whole locking scheme of gtk is flawed. The future > belongs to multi-cores, so we must expect multi-threading to become a > much more popular thing. What I did to work around the issue, was add a > couple of lines like: > > pthread_mutexattr_t gdk_lock_attr; > pthread_mutexattr_init(&gdk_lock_attr); > pthread_mutexattr_settype(&gdk_lock_attr, PTHREAD_MUTEX_RECURSIVE); > pthread_mutex_init(&gdk_lock, &gdk_lock_attr); > pthread_mutexattr_destroy(&gdk_lock_attr); > gdk_threads_set_lock_functions(lock_gdk_lock, lock_gdk_release); > > > but please be aware that some high-level gtk calls (dialogs), will > expect to implicitly be able to unlock with a single call, and this must > be handled in lock_gdk_lock() and lock_gdk_release() otherwise your app > will hang. > Now I know that some will argue that using all these cumbersome > "add_whatever_handler()", will make for much cleaner code and such, but > that just isn't good enough IMO - it makes cluttered code. I agree that > many scenarios are best handled by a model/view/ctrl setup, but > different people have different styles, and an elitist "there's only one > right way to do it" is too black and white. > > br Nikolaj > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: struggling with the non-recursive gdk_threads_enter
On Sun, Jan 4, 2009 at 5:14 AM, Alexander Larsson wrote: > IMHO that is a Gtk+ bug. I agree. Yu, can you file a bug about this ? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: struggling with the non-recursive gdk_threads_enter
On Sun, 2009-01-04 at 15:43 -0500, Matthias Clasen wrote: > On Sun, Jan 4, 2009 at 5:14 AM, Alexander Larsson wrote: > > > IMHO that is a Gtk+ bug. > > I agree. Yu, can you file a bug about this ? Yes. Filed as Bug 566578 Yu ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to use Quarks?
On Sat, 2009-01-03 at 10:40 -0500, Yu Feng wrote: > If you are accessing data member(g_object_set_data) frequently you could > use quarks to accelerate the looking up process(g_object_set_qdata). On Sun, 2009-01-04 at 14:41 +0200, Stefan Kost wrote: > If you use a hashtable with strings as keys, a lookup on the hashtable would > need to compare the strings to find the entry. ... [so GQuark] as keys > in the hashtable [is easier] This all begs a question: Is using g_object_set_qdata() and g_object_get_qdata() better because the "arbitrary data" capability in GObjects is - powered by a mechanism that is going to convert string keys to GQuarks (interning, presumably) every time for lookups, or - because it keeps two tables (one of string keys and one of integer [GQuark] keys, or - ...? ie, it sounds like we should switch to g_object_set_qdata() for our one and only use of GObject "data"; we request and set that value a *lot*, and I'm always pleased to use faster code paths. The key we use is already a static string anyway. AfC Sydney ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
