FOSS.in Conference Day 3 and Overall Impressions
This is day 3 of the conference. Reports for previous days are as follows: Project Day 1, Project Day 2, Conference Day 1, Conference Day 2.
We were slightly late for the first talk as I had some trouble checking out of the hotel. The first talk was an “Introduction into practical real-time programming in userspace in Linux” by Lennart Poettering from RedHat. Fairly informative talk. I didn’t get to jot down many notes so … 
Contributing to the Basic Runtime
Ulrich Drepper spoke on how to contribute to the basic runtime, the basic runtime here being the system API. The system API consists of many interfaces including the kernel API, processor specific code, various implementations of standards and so on. He mentioned that the C library has lots of processor specific code (which too makes up part of the basic runtime).
An important bit in the runtime is ensuring version stability. The basic runtime has not broken ABI compatibility for the last 12 years and as such, it must work with all/many different kernels, must be backwards compatible and maintain ABI compatibility.
Ulrich then listed a set of important standards:
- ISO C
- ISO C++
- POSIX
- Unix
- IETF RFC’s
- OpenMP
(all of these standards add up to several thousand pages)
The runtime can be broken down to libgcc (which GCC provides; GCC generates calls to routines in this library automatically, whenever it needs to perform some operation that is too complicated to emit inline code for), C and math libraries (which Ulrich maintains), a C++ library, OpenMP and a thread library.
Ulrich’s talk then went on to describe areas in which contributions can be made. This seems to be a good place for potential FOSS contributors (with some background in C) to contribute meaningfully.
Personal thoughts: Good, balanced talk.
talloc: The Power of C
Rusty Russell spoke about talloc. He started off by speaking about what he considers to be a myth of interface design: that interfaces should be easy to use. He felt that interface design should be structured such that interfaces should be hard to misuse as this is slightly more important then making them easy to use. He made a further observation that most of coding is about damage control - ie, ensuring that errors are correctly generated and exceptions are caught.
With that, he spoke about jitterbug, a web based bug tracking system written in C by Andrew Tridgell. He was perplexed at first when he saw that jitterbug did not free() any of the memory but that was because the operating system itself was the garbage collector (when the HTTP request died, all resources would be freed).
Rusty then jumped into some coded, gave examples of key/value allocators and illustrated the problems of memory management in such systems. There were several technological solutions for key/value allocators. First is simply not to use such systems. Second is to use garbage collectors (which don’t really work too well in critical applications, malloc overrides and memory pools.
Enter talloc. Talloc is a hierarchical allocator whereas every pointer returned from talloc is a pool. This means that free()-ing a parent node automatically free()’s all child nodes. voila, much of the memory management problems disappear. There are some program’s using talloc including talloc itself, Samba 4, NFsim and Xen Store Daemon. Apparently, Tridge spoke to Linus about using talloc in the kernel but given Tridge’s reverse-engineering of BitKeeper in 2005, Linus wasn’t too happy and talloc never made itself into the kernel.
Rusty went through some code showing how talloc can be used. He mentioned some known benefits of talloc, including it being a drop in replacement for malloc() and free() (at the cost of a small performance hit), it gives explicit documentation on the lifetimes of objects, and it helps find memory leaks. He then showed the dot graphs for SAMBA v4 allocators.
On to Q&A. First question was about how talloc allocates in pools. Rusty clarified that talloc doesn’t allocate in pools (thus there being some misunderstanding on allocation strategies) 
On scaling talloc, Rusty says that talloc scales very well, mostly on the order by O(1) although allocation itself is O(n). Another person asked whether it was possible to free() the parent node but not the child node. That question made absolutely no sense to me and apparently, it did not make sense to Rusty either. However, a child node can be moved to a different parent using talloc_steal() and the original parent node then be freed. As to whether talloc() imposes performance overhead in a non hierarchical use, the answer was not really because using talloc would not be any different from using a manual malloc(). A good question was on thread safety. Apparently, talloc is not thread safe and possibly never would be given that threads are Evil(tm)!
With that time mostly ran out and the talk was over.
Personal thoughts: Fantastic talk!
Overall Impressions
I had to go catch a plane at this point so I couldnt write down my impressions from other remaining talks. FOSS.in is a great conference. One bit which I did not blog about was the Mozilla party. I had some nice conversations with the Sun OpenOffice hackers (who strongly admitted to their Open Source and Open Standards support), met up with Danese Cooper, had a chat with GopalV (APC hacker) , Srivatsan (freenet hacker) and a whole bunch of other folk. Particularly cool was FOSS.in team making sure we got home safely from the party (thanks Shres, Shilpa, Tejas, Kishore).
The talks were great, lunch was available quickly and was decent, the organizers were freaking organized and there was hardly a hiccup visible to attendees. Well worth the visit!