PolicyKit releases and !AWOL

Marcel Holtmann marcel at holtmann.org
Thu Dec 6 17:17:05 PST 2007


Hi David,

>> you know that GLib has g_try_malloc and friends? These can be used to
>> detect OOM.
>
> I do. That won't work for things like hash tables, lists and so forth.
> Maybe glib can be fixed to return ENOMEM etc. but that isn't the case
> just yet (I'll happily switch when that happens). Also see the
> discussions on the X list a year or so ago.

some parts are a little bit problematic than others. It might be worth  
fixing inside GLib since it is more and more used in system daemons.

>> I haven't reviewed your libkit at all, but be careful with it. The
>> BlueZ project tried to avoid GLib and now we have eglib which is
>> basically a stripped down GLib. Starting with the next major version
>> number I am going back to GLib since the maintenance overhead of  
>> eglib
>> is too much. It started out very small and simple, but over time this
>> changed.
>
> One goal of libkit is that it's an implementation detail that users of
> libpolkit never sees; libpolkit never returns anything the user is
> supposed to free (lists are returned through a visitor) except for  
> class
> instances that are normally have reference counting etc.
>
> Seriously, I love glib. It's the best C library ever. It just  
> doesn't do
> what I want in this case (and of course the new polkitd uses glib; I'm
> not crazy enough to write my own main loop).

Fair enough. I wrote a main loop and I am never gonna do it again.  
Debugging its race conditions was a nightmare. It is simply not worth  
it. I can write real code in that time ;)

Regards

Marcel



More information about the hal mailing list