Re: Glib resource framework

[Alexander Larsson <alexl redhat com>]

On Wed, 2011-12-21 at 17:47 -0500, Alexander Larsson wrote:
> I just finished a one-day hackathon to add a resource framework to glib, its
> somewhat working if not very polished. Its in the "resources" branch in glib
> git.
> 
> I think this could be very useful in many places, for instance to ship built-in 
> css files, gtk builder files, win32 theme images etc in a way that still makes libraries 
> relocatable (and avoids potential for runtime errors due to not found files).
> 
> Feedback on the concept and the code welcome... Time to zzzzleep...

Ok, I pushed a few changes to the API and a few new features/fixes:

* On linux the resources end up in separate named readonly data
  sections:

  readelf -S gio/tests/.libs/resources
  ...
  [16] .gresource.test2  PROGBITS         0000000000402d38  00002d38
       00000000000000ac  0000000000000000   A       0     0     8
  ...

  This means you can extrace resources from existing binaries.

* GBytes is used in the APIs where useful

* Support for optionally compressed resources
  Note: You can only stream these, not get at the underlying bytes

* Support for locale specific resource alternative
  You can replace individual resources based on the current locale

* Guarantee zero termination of the raw data you get when looking
  up data

I think this is in a better state than yesterday. The outstanding issues
i see are:

* Documentation
* Test the constructor macros on more compilers/OSes
* We should modify gvdb so that it groups all the key strings used
  for the hash lookups consecutively, instead of mixed with the
  data. This would mean touching less pages during lookup.
* Figure out how to handle unloading

This last one is the hardest one. Right now i'm using g_atexit() from
the constructor. This means that on at least win32 and glibc >= 2.2
we'll get called when the module is unloaded, but on other arches we
might not be called until the process terminates.

Both of these create issues. 

If its called on exit we will crash on exit due to the call into
nonexisting code. But we will also be keeping registered global
resources that point into data that doesn't exist anymore.

If we get called on module unload things a much better, we will
generally not crash, and we will properly unregister the resources for
the module. However, any outstanding data (GBytes or GInputStreams) from
the resource will suddenly see their backing go away. We could possibly
keep track of these and neuter the objects, but if you have e.g. a raw
pointer to the data then there is no way to get notified of this.

I'm not sure what the best approach is here. The later problem seems
avoidable by not keeping data around for too long, but the problems with
atexit being broken is hard to work around. Is there some other
alternative though?