When building a chain of one or more Comms buffers to fulfil an allocation request, the pond uses the following rules:
First Rule: use the fewest Comms buffers possible
Second Rule: use the smallest Comms buffers that satisfy the request
With some of the Alloc() methods, you can specify size constraints for the buffer selection. You can define the minimum and maximum size of the Comms buffers in the chain, but there is a higher chance that the allocation will fail if there are no free buffers in the specified size range.
The biggest block of contiguous memory has the size of the largest Comms buffer in the pond, as returned by RCommsBufPond::LargestBufSize(). Requests for more memory than this value always return a chain of several Comms buffers.
In the following example table, the pond has two pools, respectively containing 128-bytes and 1,500-bytes buffers.
| Allocation request | 128-byte buffers | 1,500 byte buffers | Motivation |
|---|---|---|---|
3000 |
0 |
2 |
First rule - fewer buffers than, for example, 24 128-byte buffers. |
1514 |
1 |
1 |
Second rule - Less memory than two 1,500-byte buffers. |
1500 |
0 |
1 |
A buffer of the required size is available. |
1499 |
0 |
1 |
First rule - Fewer buffers than 12 128-byte buffers. |
129 |
0 |
1 |
First rule - Fewer buffers than two 128-byte buffers. |
128 |
1 |
0 |
A buffer of the required size is available. |
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.