Libical memory management

I started looking into libical code after speaking with michael meeks last week. Libical was holding 2500 memory blocks in a temporary buffer ring and was deallocating them in a round robin fashion. The memory blocks also held the strings which was given to its clients. The clients referring to this memory would not know when the string is going to be free’d. I sent my observation and approach to get this fixed to michael who immediately responded with his comments.  The solution is, now libical would not own the memory for the strings returned to the clients and it would use the buffer ring to manage the memory internally for its use while parsing the strings. This will prevent unnecessary memory being stored in libical for every thread and also fix some random crashers which happen due to the temp buffer. I have listed the functions which have been changed in libical here. The changes in EDS have been incorporated. I will be making similar changes in evolution as well probably by this weekend as I have to get on with listing sled evolution patches which needs to be upstreamed and upstream some eds opensuse patches. The other clients such as clock-applet and external backend’s might need to free the strings returned by the following functions  once the patch gets in. I thank michael in advance for his patch review too :)

About these ads

6 thoughts on “Libical memory management

  1. Hi Chenthill,

    libical is used in a couple of other projects too – we use it in the Bongo project, and I think the Citadel people have a copy of that library too.

    It would be great to have libical be a standalone, independent library outside of EDS so that others could contribute to its development too – would you be interested in that at all?

    Alex.

  2. Alex,

    Libical is a seperate project by itself. It lies under svn.gnome.org/libical . Just the EDS checkout links a checkout of libical also. Otherwise, nothing so closely related :)

  3. Currently I suppose EDS is the only module in GNOME which uses libical and so we did not want to spend much effort on getting it as a standalone library. I am not sure about the reason why libical was made as a separate GNOME module although its also in upstream at http://freeassociation.sourceforge.net/ . I will need to know why that was done. I would be definetly happy in having it as a standalone library if it facilitates to have contributors. I will get back to you soon on it.

  4. I do believe from recent chatter on the libical list there is an effort at the moment to merge all the divergent forks of the library.

  5. Pingback: EDS calendar memory « A drop in the ocean

  6. libical upstream is maintained as a standalone project, and there is an effort underway to get everyone tracking the upstream again. Anyone maintaining a fork is *strongly* encouraged to help out with this effort.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s