On Mon, 28 Jul 1997, Patrick J. Dughi wrote:
> A "buffer" is usually a pre-allocated space in memory, which is
>used to hold temporary data. This buffer is just used for scratch
>information like "Banzii hits the troll with a mindblowing pierce" or
>whatever. Usually, buffer information lasts about as long as the function
>that uses it (unlike character information, world info, etc..). Now, the
>main problems are threefold:
Exactly.
> 1) if you use a global buffer (like circlemud has several of), you
>have to make sure that its clean before you use it, else you'll get the
>remenants of some other buffer info.
Another fun quirk is that if you use a buffer that some other function is
currently using under the CircleMUD system, you get _really_interesting
output as the first function has no idea its buffer changed.
> 2) You have to make sure that your buffers are correctly sized. If
>they are NOT the correct size, you can overwrite them, which will make
>everything in your mud act funny, and then end up in a happy mud crash, or
>simply cause everything to just quit.
A stack overflow took me 30 days and one bug to fix. Overwriting any
buffer automatically allocated in a function (like char buf[123]) will
cause bad things to happen, it's not quite so bad to overwrite malloc'd
memory I used in the buffer patch. (No 'overwrite the stack' security
exploits that proliferate on security mailing lists for one.)
> 3) Since these buffers are accessed SO much, it does become an
>issue how fast they can be used. If the buffers need to be created each
>and every time they're used, they will cause the program to run slowly. If
>they are already created, you have to make sure they're the right size.
>And if you're using more than one, you have to make sure that each one
>gets the right one of the right size, else you cause more overhead if
>other functions have to wait to use these buffers.
It's kind of hard to wait for buffers in CircleMUD so the best thing is to
just make more buffers. (a la the comm.c buffer code)
> Now, if i remember right (i have only had time to peruse the
>code), the buffer code creates a bunch of buffers on demand, and stores
>them for useage, cleans them when they're not in use.. stuff like that.
>So, you don't have to make new buffers, or depend on incorrectly sized,
>inefficent global buffers. Ie, solves problems 1,2,3 above.
Exactly, if there isn't one, it makes it. If a buffer isn't used for 5
minutes, it's removed. If someone forgets to free the buffer, the function
that forgot to free it is printed out and the buffer released.
> Of course, I could be wrong. =) Simply reviewing the code posted
>should be able to describe its functionality.
You were really accurate in your description, which is why I quoted
everything, so people could read it again if they skipped it. :)
Working on completing the patch to convert all char buf[xxx] calls to
get_buffer() calls...
--
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