Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libvirt: Adoption of GLib library to replace GNULIB and home grown code

berrange.com

Post reply on HN
Print view View original

11–20 of 66 posts

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#11

Post by wahern »

lrossi wrote: post #5
lrossi wrote: post #3

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 r…

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.

The BSDs basically solved this problem decades ago: and 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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#12

Post by pmiller2 »

lrossi wrote: post #3

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 r…

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#13

Post by ognarb »

loeg wrote: post #4
marktangotango wrote: post #2

> 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 ab…

If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#14

Post by saurik »

marktangotango wrote: post #2

> 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 ab…

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#15

Post by lrossi »

ognarb wrote: post #13
loeg wrote: post #4

Earlier quoted context omitted.

If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.

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.

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#16

Post by baybal2 »

lrossi wrote: post #9
the_why_of_y wrote: post #8

Earlier quoted context omitted.

Did you try to disable the slab allocator? https://developer.gnome.org/glib/stable/glib-running.html#G_...

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 durin…

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#17

Post by attractivechaos »

lrossi wrote: post #5
lrossi wrote: post #3

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 r…

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.

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#18

Post by lrossi »

baybal2 wrote: post #16
lrossi wrote: post #9

Earlier quoted context omitted.

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 durin…

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 w…

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.

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#19

Post by tyingq »

marktangotango wrote: post #2

> 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 ab…

Qlibc: http://wolkykim.github.io/qlibc/

Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code

#20

Post by inetknght »

lrossi wrote: post #3

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 r…

> these days there is no reason to cache and reuse allocations.

No, you are wrong. Ideas like that are a big reason that apps get slower despite hardware getting faster.

Post reply on HN