George writes:
>Anyway, as per an idea from Jeremy, I'll be attempting to move the socket
>buffering code onto my buffer system. Then we'll finally have the ability
>to free large buffers with a timeout value. I'm thinking that just
>allocating them on the same buffer chain as everything else would work
>best. I just increase the number of persistant buffers available.
>
>Main problem is that my (2*) patch is the only time I've every really
>delved into the comm.c buffers...
>
>Any opinions? Should we keep all the user buffers on a separate chain and
>allocate say...1 small buffer for every 2 characters and 1 large buffer for
>10? Or should we just keep it one chain and increase the number of general
>persistant buffers? (my current favorite)
>
Small buffers should probably remain as they are (static buffers
associated with the descriptor) because it'd just be a waste of
resources to constantly be allocating them and deallocating them --
the only memory savings would be for idle players.
Large buffers, on the other hand, should probably be part of the new
buffer system. No persistent buffers are needed (assuming I'm
understanding your concept of "persistent" from reading the buffer
patch.) Large buffers are used frequently enough that some of them
will never time out, so the system will automatically settle on some
number that are essentially "persistent".
This brings us to an interesting point: When a buffer is requested,
the request should be fulfilled by the (large enough) buffer most
recently used. Otherwise, successive buffer requests will cycle
through all available buffers and none will ever time out. Letting
unused buffers age can be easily assured by prepending freed buffers
to the free list and then taking the first one that appears in the
list when one is requested.
-Jer
+------------------------------------------------------------+
| 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