Why there are no *_new_full–like functions that would take an allocator?

Hi,
I’ve noticed that you apparently cannot set e.g.: g_slice_* allocator for e.g.: pointer arrays, arrays, g_sequence_* collections etc. I wonder if a contribution that would provide such functions (e.g.: *_alloc_full) and extend the possible data structures (seems to me that all except G(S)List of them qualify) with such functionality would be accepted?
I’m a very passionate open source programmer with plenty of time (I’ve did e.g.: 300 commits to Midnight Commander fork NeoMC but changed the repo to a private one because I’ll be selling it) and I’m quite fascinated by GLib structures, so I can invest some serious time into uplifting GLib.

No, we don’t really want to provide a “use an allocator” variants for our data structures. The allocation is completely opaque for a reason.

Additionally, we’re not entirely sure the benefits of the slice allocator are still worth it in 2021, and we might replace its internals with malloc()/free().

1 Like

OK. I’m just noting that allocator support would be only partially overlapping GSlice – setting an allocator would be a feature on its own right and such flexibility could provide some useful use cases (like e.g.: helping to debug a memory problem by providing an ability to hook into alloc and free operations).

I think the suggestion there would be to just use asan or valgrind.

Just IMO, it seems infeasible to have custom runtime allocators in glib without a massive ABI break. There are a lot of functions that do small allocations (strings, small structs, etc) that would probably all need to be changed to use allocators.

Yes, definitely. libc provides enough hooks into malloc() that there’s nothing new or useful GLib can add here, and the downsides are pretty numerous:

  • Having to maintain an allocator
  • Having twice as many API entry points to maintain
  • No longer knowing through the type system which free function to use to free a particular structure instance, which I suspect would break all the language bindings
  • Having to integrate whatever new allocator we invent with all the existing memory debugging tooling and documentation
1 Like

Can I have a copy of the source?

1 Like

Yes, you can, visit neomcedit.software for details. The page isn’t yet fully ready, but it’s close to such state.

I know that the proposition has been rejected, I just want to address some of the highlighted problems:

  • Having to maintain an allocator

No need for shipping an allocator. It would be up to the user if he would want a custom one.

  • Having twice as many API entry points to maintain

The current constructors (*_full) would simply call the alloc versions (say, *_alloc_full) with the malloc as the allocator. So basically, after extending the current full constructors with the allocator parameter and renaming them to *_alloc_full an almost empty full-only allocator would simply delegate the work to the renamed one, passing malloc. There would be zero need to maintain them.

  • No longer knowing through the type system which free function to use to free a particular structure instance, which I suspect would break all the language bindings

Why? It would take free-function from the same place as it does now – from a private field in the type’s structure. It could be g_free or something else.

  • Having to integrate whatever new allocator we invent with all the existing memory debugging tooling and documentation

As in the first item – no custom allocator have to be provided by GLib. If user would provide one, then basing on what you’ve wrote there would be a problem with the tooling, however, I’m not sure if any code/tool depends on allocator being malloc, if GDestroyNotify doesn’t have to be g_free? Isn’t it the same for (saying by analogy to keep it short) “GAllocNotify” ?

Hmm, I seem to have missed the download button somehow…