[HN Gopher] Libvirt: Adoption of GLib library to replace GNULIB ...
___________________________________________________________________
Libvirt: Adoption of GLib library to replace GNULIB and home grown
code
Author : adgnaf
Score : 27 points
Date : 2021-01-21 10:30 UTC (1 days ago)
(HTM) web link (www.berrange.com)
(TXT) w3m dump (www.berrange.com)
| marktangotango wrote:
| > These problems are common to many applications / libraries that
| are written in C and thus there are a number of libraries that
| attempt to provide a high level "standard library". The GLib
| library is one such effort from the GNOME project developers that
| has long been appealing.
|
| I've been a fan of glib for some time, other than glib and apache
| libapr, what other "high level standard libraries" for C should I
| know about?
| loeg wrote:
| If your C umbrella includes C++, Qt has a number of (non-GUI)
| high-level libraries that can be useful for applications.
| lrossi wrote:
| Qt is more like gtk rather than glib. Although it does come
| with a fantastic core library.
|
| But if you can move to C++, the standard library already
| offers great replacements for most glib features. Glib exists
| mostly because the C standard library is lacking in many
| aspects.
| ognarb wrote:
| There is QtCore that is more similar in scope to glib and
| only containers, json and a few more useful stuff. It's a
| sort of alternate C++ standard library.
|
| Personally I wonder why people would choose today using C and
| Glib over C++ for system programming. I could understand why
| not Rust but for having to deal with glib in the past its so
| much of a pain.
| lrossi wrote:
| That's exactly what I am thinking as well.
|
| Using C++ in moderation, without getting too crazy with
| classes, multiple inheritance, lambdas and other such
| things, works very well if you want to port a legacy C code
| base.
|
| For a new project, there are many choices: rust, go etc.
| JNRowe wrote:
| I can't offer extra recommendations, but just wanted to offer
| full agreement.
|
| GLib is the awesome standard library I get to use everywhere
| thanks to gobject-introspection. From work projects in Vala,
| window manager1, image viewer2, video player3. It is especially
| useful with lua configurable projects, given the sparsity of
| the language itself.
|
| 1 https://awesomewm.org/
|
| 2 https://github.com/muennich/sxiv - my user configs are lua &
| lgi, extended with gexiv2 also via gobject-introspection.
|
| 3 https://mpv.io/
| saurik wrote:
| https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...
|
| > Netscape Portable Runtime (NSPR) provides a platform-neutral
| API for system level and libc-like functions. The API is used
| in the Mozilla clients, many of Red Hat's and Oracle's server
| applications, and other software offerings.
| lrossi wrote:
| Glib is OK except for the fact that it has a memory cache on top
| of that of malloc. This prevents tools like asan or valgrind from
| detecting memory related bugs. It caused my team a lot of grief,
| to the point that we regretted the choice of using glib in the
| first place.
|
| I am not sure why there is a memory cache in the first place.
| Malloc may have been slow in the 90s, but these days there is no
| reason to cache and reuse allocations.
|
| It's also a major security risk, since it nullifies hardening
| measures from the standard library, as we have seen with
| openssl/heartbleed recently.
| lrossi wrote:
| Another problem is that there is no type checking in the
| containers. So you have to cast everything to/from void
| pointers, even for basic structures like lists and arrays. This
| makes it easy to introduce tricky bugs.
| wahern wrote:
| The BSDs basically solved this problem decades ago:
| <sys/queue.h> and <sys/tree.h> provide type-safe core data
| structures sufficient for most C application needs. The
| amount of wheel reinvention and dependency complexity outside
| the BSD universe blows my mind. (Though, FreeBSD projects do
| have a greater tendency to complicate things, perhaps owing
| to the stronger corporate-induced feature chasing.)
|
| The only real universal sore spot IME has been arrays and
| vectors. But nobody seems to pitch glib as a way to get a
| fast and ergonomic FIFO buffer. There are many other areas
| without simple, go-to solutions, but then that's the nature
| of C programming. Most of the C programmers I interact with
| are multi-language programmers, as opposed to many C++, Java,
| etc engineers who lean toward single-language, monolithic
| approaches.
|
| I can understand using glib for GUI applications, considering
| it's already a requirement for Gtk, and because of the OOP
| emphasis in GUI programming. But IMNSHO, in most other areas
| the _right_ reasons for selecting C as your implementation
| language are mutually exclusive with the need for cookie-
| cutter, void-pointer heavy data structure implementations a
| la glib.
|
| EDIT: Removed outdated discussion of systemd + glib.
| attractivechaos wrote:
| In addition, using void pointers harms performance as this
| strategy often incurs additional heap allocations, hurts
| memory locality and prevents compiler optimization.
| Personally, I avoid glib like a plague.
| asveikau wrote:
| Curious for some details. On what layer does that caching
| occur?
|
| I immediately thought g_malloc but it seems to call directly to
| libc: https://github.com/GNOME/glib/blob/master/glib/gmem.c
| pmiller2 wrote:
| I don't know anything about this cache you're referring to,
| but, is it so pervasive within the library that you can't
| easily do a patch to remove it? Would such a patch be accepted
| by upstream? If you're opposed to using the environment
| variable, those would be my next thoughts if you wanted to get
| back the ability to use valgrind _et al._
| the_why_of_y wrote:
| Did you try to disable the slab allocator?
|
| https://developer.gnome.org/glib/stable/glib-running.html#G_...
| lrossi wrote:
| I am aware of that environment variable. The problem is that
| I think almost nobody is using it, so it could come with a
| risk of introducing more bugs.
|
| By the way, the example shown in the documentation page that
| you link to seems ridiculous: void *slist =
| g_slist_alloc (); /* void* gives up type-safety */
| g_list_free (slist); /* corruption: sizeof
| (GSList) != sizeof (GList) */
|
| This bug should actually be caught during compilation if we
| store the list in a GSList* typed variable instead of void*.
| You'd think: who does that?
|
| Except that this is what you actually end up doing when using
| any kind of nested glib containers. Elements are always
| void*, so you have to cast them correctly. So for non-trivial
| applications, it's very easy to make mistakes, since you lose
| the type checking support of the compiler.
|
| C is already a tricky language. Removing the type checker
| makes it even worse.
| baybal2 wrote:
| You seem to know a lot about Glib. What did you do with it?
|
| I looked to port Gtk to MCU, and then gave up. Too much C
| trickery, and hard to replace, heavy dependencirs.
|
| For somebody who knew Qt, and Gtk since 2003, it looks like
| a miracle now how Qt got smaller, and faster than Gtk, and
| can even run on an MCU, and quite well!
|
| Very big contribution to that was Qt's team willingness to
| undo the wheel reinvention, and willingness to throw out
| their hacky attempts to replicate new c++, and standard lib
| functionality.
|
| The Glib+Gtk world, unlike Qt, still lives in ANSI C, and
| C99 era, and refuses to concede on reinventing
| functionality of modern standard libraries, language
| features, and compilers.
| lrossi wrote:
| I worked on some Linux apps in another life. I switched
| to Qt at some point. It was a breath of fresh air! Qt is
| very reliable and well documented. One can be very
| productive with it.
|
| I think a lot of people have a bad opinion about it as
| they confuse it with KDE. While KDE does use Qt, the two
| projects are otherwise independent.
|
| I've also looked inside the Qt code base a few times.
| It's very tidy and quite easy to read. You can tell that
| their team is very experienced. I used to read their blog
| as well, they had a lot of good articles.
|
| I really hope that they can continue to survive
| financially. Selling a mostly open source library is not
| very profitable.
___________________________________________________________________
(page generated 2021-01-22 23:00 UTC)