Re: patch #4 - mdebug

Hi, David.  I havent had much time to work with EPS in the past few
days, and Ive got a conference coming up, so Im going to be pretty busy
for the next week before I can work on releasing the next version of
EPS,
but I wanted to touch on this email in case I didnt already.

If you're going to be using INTERFACE_BUFFER, then you probably dont
want
to use line_inject() to allocate the email.  Im not sure what your
environment
is, but in eFilter, for efficiency's sake, I try to average the size of
the
emails coming through, and keep memory pre-allocated for email storage. 
Then,
I can simply read into that buffer, and if need be, re-allocate at that
point.
Then simply fill in the line_t structure's contents, by handing it the
memory
space, and the size of the memory space.  line_inject can be kinda
inefficient
with all those realloc() calls and such, so I like to avoid using it
where
possible.  Fortunately, it is efficient enough to be used when there is
no alternative.

So, I just wanted to give you an idea of how I handle messages when I
dont know
their exact size.  I dont call line_inject() :P

David Relson wrote:
> 
> Hello Matt,
> 
> Given my previously described design for using eps, I load the message into
> a struct line_t using line_inject().  Not unexpectedly, the buffer is
> filled and must be reallocated.  In eps-1.2 and eps-1.4, line_inject()
> calls the library realloc(), even with MEM_DEBUG enabled.  This causes a
> problem as the memory supplied by realloc() is eventually passed to
> mdfree() which doesn't like it (as the memory is not on the xptr_list).
> 
> Calling mdrealloc() isn't quite good enough because _it_ calls realloc()
> and mdfree() still isn't happy.
> 
> The solution I found is for mdrealloc() to call mdmalloc() for a new
> buffer, copy the old data to the new buffer, and call mdfree() on the old
> data.  This maintains the validity of the xptr_list, although it is
> slow.  Given that MEM_DEBUG is turned on for a reason, the speed penalty is
> acceptable.  When MEM_DEBUG is off, the mdrealloc() call will go to libc's
> realloc().
> 
> The attached patch affects line.c, misc.h, mdebug.h, and mdebug.c.  In
> line.c the change is from calling realloc() to calling mdrealloc().  In
> misc.h, the changes are to let mdebug.h define the debugging forms of the
> macros.  mdebug.h has the debugging versions of the macros and mdebug.c has
> the reworked version of mdrealloc().  I've also change the type of the
> length parameter to size_t (for consistency with libc) and of the where
> param from an unsigned pointer to a const pointer (which is correct).
> 
> With the above changes and a final call to eps_end(), my test program runs
> to a happy conclusion with zero unreleased bytes to clean up.
> 
> Cheers!
> 
> David
> 
>   ------------------------------------------------------------------------
>                    Name: mdebug.patch
>    mdebug.patch    Type: unspecified type (application/octet-stream)
>                Encoding: base64
> 
>   ------------------------------------------------------------------------
> --------------------------------------------------------
> David Relson                   Osage Software Systems, Inc.
> [email protected]       Ann Arbor, MI 48103
> www.osagesoftware.com          tel:  734.821.8800

-- 
mailto:[email protected]
Matt Brookings - Chief Technical Officer
Inter7 Internet Technologies, Inc.
www.inter7.com - 847-492-0470
Prices at http://www.inter7.com/prices