On Wed, 20 Aug 1997, Jeremy Elson wrote:
>George writes:
>>print_object_location:1354 requested 8192 bytes, received 12320.
>>write_to_output:987 requested 12288 bytes, received 32384. (***)
>
>This is a good example of why the buffer-selection policy needs more
>work, though - maybe using best fit instead of first fit. Of course,
The list is sorted ascending so the best buffer will also be the first
found. If all the appropriate sized buffers are filled, it defaults to
using the next largest free buffer found instead of malloc()'ing yet
another buffer. This prevents such cases as trying to allocate four 128
byte buffers and having to create one when you run out even though there is
a perfectly suitable 512 byte buffer next in line.
Request for 8192 bytes flow:
256 <- too small
256 <- too small
512 <- too small
512 <- too small
1024 <- too small
8192 <- used
8192 <- ok!
12320
16384
or also possible for 8192 bytes:
[...etc...]
1024 <- too small
8192 <- used
8192 <- used
12320 <- ok! (even though to big)
or if nothing is free:
8192 <- used
8192 <- used
12320 <- used
16384 <- used
<malloc 8192 and insert before other 8192 byte buffers>
Due to this it is better to do smaller allocations first _if_ you are doing
a very large number of them, a la do_users(). If you're not allocating a
whole lot then you'll probably fit perfectly in some buffer.
I've also added a PICKY_BUFFER option to catch any buffer overruns when the
buffer given out is larger than was requested. There is not guaranteed
memory corruption but your code has a serious problem (just think if it did
receive the correct size buffer later) and a reboot is recommended.
(released later)
--
greerga@muohio.edu me@null.net | Genius may have its limitations, but stupidity
http://www.muohio.edu/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST