So in my last post I had mentioned some of the issues that have been encountered with KPixmapCache, and that I was working on a separate implementation.

Based on the fact that the underlying code is easily made more general purpose I’ve gone ahead and went down that path. With that in mind, the current code I have is available from a branch of kdelibs that I’ve made a few hours ago, called kdelibs-shareddatacache, available from /branches/work. This branch adds a class called KSharedDataCache, adds a KImageCache which operates on top of KSharedDataCache, and updates Plasma::Theme and KIconLoader to both use KSharedDataCache.

I don’t have time to go over the implementation details (I’ll try to do so this week if I get time though) but I will throw out the following:

  • My port of KIconLoader was so much of a hack that the original KIconCache is still there! It’s just not being used for icons. I think the Plasma::Theme work is a little cleaner but probably could be better handled itself.
  • Changing the icons requires a separate patch to kdebase/runtime/kcontrol/icons that I will apply if this should ever land in trunk. (It’s a bit faster too…)
  • On the topic of speed, I don’t have any benchmarks, mostly because that wasn’t the reason I was mucking about in the cache. It seems a bit faster to me but I’ve done no formal testing.
  • My larger concern was correctness. Absolutely everything is locked (double-locked in one particular scenario I was able to think of, look in the code if you’re interested…) and things seem to pass the consistency tests I’ve been able to throw at it now. The limited testsuite for kiconloader seems to work as well.
  • This work depends on having a pthreads library with “process-shared” locking primitives (at the very least mutexes) but I have not added relevant CMake checks yet.
  • Now that I think about it I also probably should be using timeouts and checking some more return codes here and there.

It’s available if you’re interested though. If you do go this route, I have an auxiliary tool which you can use to view the contents of a cache:

It obviously requires the headers for the new classes so you will need to have installed the modified kdelibs. You can download the source from http://purinchu.net/dumping-ground/cacheviewer-1.0.tar.bz2. When it asks for a cache name, just give it one of the *.kcache files in your /var/tmp/kdecache-$USER directory (examples: icon-cache or plasma_theme_Aya (or whatever theme you’re using)).

(By the way, isn’t it *scary* that the icon cache had been accessed more than 100,000 times in a 12-hour period? ;)

2 thoughts on “KSharedDataCache

  1. Diederik Identicon Diederik

    Quite interesting to read! It did left me to wonder, what are the performance/memory improvements you expect, and what double-initialisation are you solving here?


  2. mpyne Identicon mpyne Post author

    Diederik: Honestly this is mainly for correctness as opposed to performance/memory improvements. I’ve not benchmarked so I don’t want to guess on figures. Some operations are way more efficient because of the implementation (for example, deletion of old cache entries is much, much more efficient since it does not involve shrinking the cache all at once when the cache finally gets too full). As far as memory improvements, I haven’t managed to fill up the default 10 MiB icon cache yet in normal operations so it seems fairly memory-friendly. We’ll see.

    As far as the double initialization, if you’re referring to what I think you’re referring to (the atomic integer initialization until == 2) then the issue is that the very first time the shared memory segment is created, the memory defaults to 0, so we can’t distinguish 0 from plain unused memory. We could use a value of 1 to indicate an initialized cache, but we’d need a way to indicate a cache that has been created and is *being* initialized, but is not fully initialized. So, I chose to use 1 as “being initialized” where we do the once-per-lifetime mutex setup, and 2 to mean “fully initialized” where we know that the necessary data structures have been setup and it is safe to use the cache. Of course, it is very important to ensure that the transition from 0, to 1, and to 2 happens in a thread-safe manner. Hopefully I’ve got that right. ;)

Comments are closed.