Hi folks, I'm designing a site written entirely in C-based modules - much of the work the modules do involves storing and reading small items of data (in the order of 40 bytes) in linked lists. The data will also stored in a database for backup, and for more general access. The reason to store it in linked lists is that it will be faster to store it in sorted form and then read directly from main memory, rather than read it from a database, sort it, build a linked list, manipulate the data, write to the database and then free the list.
Since I'm not going to be using the tcl capabilities of AOLServer (why use AOLServer? I like the C API, the multi-threading and single-threaded async IO), can I run it without the tcl interpreters? I've been reading that it starts a tcl interp for each thread and these take up memory. In this application, there will be detached threads servicing connections. Each of these may store data in the lists (with appropriate mutexes), but my understanding of the Zippy allocator is that each thread will have it's own heap, so that adjacent items in the lists may in fact be quite distant in terms of system memory. Since they are small, it would seem advantageous for them to be located within the same 4K page for instance. (Would this make any noticeable difference?) I have looked at Hoard (http://www.hoard.org - actually there's a thread about Hoard in the AOLServer archives from around 2 years ago - Jim Davidson talked of perhaps integrating Hoard into AOLServer) and ColdStore (http://coldstore.sourceforge.net/), and ColdStore looks quite useful for this purpose. It also looks good perhaps as a low-level database (it has database indexing and BTrees built in) and since it is thread safe, it should be easy to integrate into AOLServer. What do people think of ColdStore's usefulness? Would it be worth it for this project, or shall I just stick with the standard allocators? I reckon it may be an elegant way to lessen the reliance on more expensive hardware. I look forward to your thoughts. Cheers, Jason
