Re: buffers...

From: George (greerga@DRAGON.HAM.MUOHIO.EDU)
Date: 09/16/97

On Tue, 16 Sep 1997, Angus Mezick wrote:

>     my problem was that at one point a lot of zones would idle out and
>     send a message to that effect using mudlog{f}() which would put it
>     into a buffer of MAX_STRING_LENGTH and the pass that through
>     send_to_char to write_to_output.  well write_to_output has some nice

You should probably reduce the size of that buffer to mudlog. (not

>     error checking features (doesn't let the buffer get too large.  a
>     small problem with it, is it has a hard limit for the ammount input at
>     one time and if it switches to the large buffer, and that is still too
>     small... BANG that person is dead. nothing goes to their screen.  Now

In all my 'where sword' abuse I always got *OVERFLOW* as usual for

>     the question is, where to fix this mess.. (well.. I have to fix the
>     overrun buffer in mudlog{f}(), but is there something for
>     write_to_output to help this along?

Code in process_output will switch them back from a large buffer if it
   * if we were using a large buffer, put the large buffer on the buffer pool
   * and switch back to the small one
  if (t->large_outbuf) {
    t->large_outbuf->next = bufpool;
    bufpool = t->large_outbuf;
    t->large_outbuf = NULL;
    t->output = t->small_outbuf;
    t->output = t->small_outbuf;

Code in flush_queues:

   * As I understand this, it puts the buffer back on the list.
   * So we don't need this anymore as it is.
  if (d->large_outbuf) {
    d->large_outbuf->next = bufpool;
    bufpool = d->large_outbuf;

and of course the write_to_q code are the only changes.

Try defining USE_CIRCLE_SOCKET_BUF and see what you get.

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/08/00 PST