[TCLCORE] Re: Hintermayer's string allocation patch

[Jeffrey H. <jef...@aj...>]

> From: Scott Stanton [mailto:st...@aj...]
	...
> George Howlett said:
>
> > But if one still wants to handle this within Tcl, I have a slightly
> > different tact.  When realloc fails, pull back the size.  It can fail
> > when you can't allocate even the extra space needed.
>
> Jeffrey Hobbs said:
>  >  The other suggestion in the thread was a fall-back allocation
> mechanism,
>  >  whereby one still goes for *2 all the time, until malloc says, "No".
>  >  Then we would try for just what we need (or a bit more), and see if
> that
>  >  works.  However, that requires changing around the ckalloc routines,
>  >  because they panic by default when malloc returns NULL.  You'd have to
>  >  create some sort of alternative like:
>  >
>  > 	bytes = (char *) ckallocEx(howMuchIWant, howMuchINeed);
>
> I think we should really consider implementing this approach.  So far,
> this sounds like the best approach anyone has mentioned yet.  It only
> costs you when you really run into the large allocation failure case.
> Arguably, the dynamic string mechanism should be in cahoots with the
> memory allocator for optimal performance anyway.  It wouldn't be that hard
> to add an alternate entry point that doesn't panic on malloc/realloc
> failures and then build the double realloc behavior on top.  This seems
> like a simple way to get the best performance while still allowing very
> large allocations.

I think it would be valuable to have a cross-platform malloc wrapper that
didn't panic.  Upon that you could build better fall-back algorithmns.
The example above is just a limited one-case fall-back, and if we want to
get more elaborate, we're still SOL.

At the same time, the new APIs could be done using the proper casts (size_t),
in preparation for 64-bit support.

In any case, we still need to allow the Tcl string allocator a way to not
be so aggressive in large string situations.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.