Review Board 1.7.16

Convert pbx_spool to use string fields

Review Request #168 - Created Feb. 19, 2009 and submitted

Mark Michelson
Simple. Convert all the static buffers used in pbx_spool to be string fields. This will dramatically lower the amount of memory used when processing a call file.
It compiles.
Review request changed
Updated (March 1, 2009, 10:58 a.m.)
Fix a logic error in init_outgoing. A zero returned from ast_string_field_init means success, not failure.

I ran some tests with this, first to make sure that call files were still working as expected, and then to see about the memory difference. I tried the following simple call files for accuracy:

Channel: Local/037@internal
Application: Wait
Data: 10000
Callerid: "Mark C Michelson" <1234567890>
Account: GHY329201SHK390

Local/037@internal answers and waits for 5000 seconds. The other call file I tested for accuracy was the following:

Channel: SIP/2001
Extension: 2000
Context: internal
Priority: 1
Callerid: "Mark C Michelson" <1234567890>
Account: GH2389SKDI321

Extension 2000@internal dials SIP/2000. Both worked as expected when moved to the outgoing spool directory. I reran the first test with malloc debug enabled and found the following allocations without my patch applied:

2024 bytes allocated in pbx_spool.c
337804 bytes allocated in utils.c

With my patch applied, the allocations changed as such:

168 bytes allocated in pbx_spool.c
337940 bytes allocated in utils.c

Without my patch applied, the allocations in utils.c can all be attributed to other goings-on in Asterisk. So the total number of bytes used to process the call file was 2024. With my patch applied, we have both the allocation in pbx_spool.c plus the allocation for the string field pool(s) inside utils.c. With my patch applied, the total number of bytes allocated for call file processing was 168 + (337940 - 337804) = 314 bytes, a reduction of ~84.5%.

While such savings probably won't be noticed by those who run just a few call files, it will be welcome for those who run hundreds or even thousands of call files at once.
Ship it!
Posted (March 2, 2009, 5:52 p.m.)
Looks good
  1. Also, very nice work on the summary of your last update!  This is a great example for others to follow. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to