[TCLCORE] Re: Hintermayer's string allocation patch

[John O. <ou...@aj...>]

At 01:45 PM 8/31/2000 -0700, Jeffrey Hobbs wrote:
> > From: George Howlett [mailto:ga...@si...]
>         ...
> >  :  However, that requires changing around the ckalloc routines,
> >  :  because they panic by default when malloc returns NULL.
> >
> > In 8.3, "ckalloc" (TclpAlloc) panics at memory exhaustion only when
> > you have compiled with -DTCL_DEBUG and -DUSE_TCLALLOC=1.  If it does
> > otherwise, then TclpAlloc is broken.  The implication from the manual
>
>Well, that's just the way it is.  Tcl_Alloc/ckalloc *will* panic in
>Tcl (since 8.1) if you get a NULL from malloc.  This has been hashed
>out in numerous newsgroup threads.  The basic reasoning that I've heard
>(I wasn't around for this decision), is that if you are running out of
>memory, you're screwed.  It's better to panic with the "Unable to alloc"
>message than it is to follow on and fail because nowhere does the core
>actually handle a NULL return from ckalloc.

This is one of those issues that keeps coming up over and over again
when people learn about the behavior for the first time.  There's a
much better reason than "that's just the way it is".

The reason for the behavior is that recovering from memory outages
just isn't possible (IMHO).  There are way too many places where
memory is allocated, so it would add a lot of complexity to Tcl to
try and behave reasonably in every instance.  Furthermore, it is
difficult to figure out how to test memory exhaustion in all of these
places reliably, so in practice recovery wouldn't work ("if it hasn't
been used, it doesn't work").  Lastly, the whole idea of recovery
assumes that Tcl could do something useful even if it ran out of
memory, and that isn't true.  Dynamic memory allocation is used
*everywhere*, even in the guts of the interpreter.  So, if you run
out of memory, you can't necessarily even execute scripts to free
up memory.  Bottom line: better to panic cleanly with a nice simple
error message.

-John-
________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
http://www.ajubasolutions.com

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