Re: Buffer Addon: Those silly release_buffer calls

From: George (greerga@CIRCLEMUD.ORG)
Date: 05/06/98

On Wed, 6 May 1998, Gary Barnett wrote:

>The buffer system is all well and fine, I didn't have any difficulty
>determining how it works or how to get it functional.

Good, I might end up actually working on it again shortly. (Now that I
found a little manual on POSIX thread locking for real.) :)

>However, it has become time to add all the release_buffer calls and with
>2798 get_buffer calls I find myself dreading the prospect.

I know what you mean, I had a lot of them in for the 1.5 release (I think)
but gave up trying to finish it for the 1.6 release.  I ended up only
changing the output buffer calls.

>I cannot do them a little at a time, as I can't place into production a
>mud that uses 180megs of ram at startup before the buffers time out and it
>settles down to 10 megs (which is a nice reduction from before I started
>adding the buffer system.)

You can add calls to release_all_buffers() in strategic points of the
bootloading.  It's a hack but that's what I did whilst trying to hunt down
all the release_buffer() calls I missed in v1.5.

>1) Write a program to read the source and put all the release_buffer calls
>in for me.
>   a) search for all get_buffer calls in the file
>   b) with each get_buffer call, read the source until you get another void,
>int or struct, acmd call (not prototype).
>      1) if you find a return, either warn or add the release buffers there

Personally, I'd have it warn about every function with a get_buffer()
without a release_buffer().  I wouldn't get into the added complexity of
having the program figure out if the buffer _might_ not be freed.  That's
why the 'forgot to free' message is there.

>2) Use a call to 'register' the buffers
>    a) update register buffer to allow buffer requests w/o intervening code
>to count as one entry in structure
>    b) #define RETURN {release_my_buffers;return;}
>    c) remove all buffers from the 'last' entry in a)

Version 1.3 used to have:
#define release_and_return     release_my_buffers(); return

Nowadays, I'd say to use:

#define release_and_return(x) do{release_my_buffers();return(x);}while(0);

You have to use "return (x);" instead of "return x;" but that's it.

Note that you have to have GCC for 'release_my_buffers()' to work properly.

>3) Store the function being processed in a local var for each function. Use
>that to figure out what buffers are in use by the function. This would
>require storing instance data in a static var for recursive routines.

Add "show_buffers(NULL);" to parts of code where you want to see who is
using what.

>#2 would probably become a mess and redefining return seems wrong.

Version 1.3 of the patch did that a lot...

>#3 would waste a lot of memory storing function names and the static int for
>recursion would be easy to mess up.

show_buffers() and release_my_buffers() should help until you do something
more proper.

(Of course, if your MUD is C++, or C++ capable, I have a mostly working C++
Buffer class you can basically drop in in place of 'char *'s.)

George Greer, | Genius may have its limitations, but          | stupidity is not thus handicapped.    |                  -- Elbert Hubbard

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST