On 19 February 2015 at 13:40, Peter Kelly <[email protected]> wrote:
> > On 19 Feb 2015, at 7:06 pm, Dennis E. Hamilton <[email protected]> > wrote: > > > > +1 about a cheap check and common abort procedure for starters. > > > > I think figuring out what to do about cleanup and exception unwinding, > and even what exception handling to use (if any) is a further > platform-development issue that could be masked with simple > still-inlineable code, but needs much more architectural thought. > > I’m fine with us using wrapper functions for these which do the checks - > though please let’s use xmalloc, xcalloc, xrealloc, and xstrdup instead of > DFPlatform* (it’s nothing to do with platform abstraction, and these names > are easier to type). (as a side note we can probably cut down on prefix > usage a lot as long as we don’t export symbols; this was just to avoid name > clashes with other libraries) > +1, I take that as a general statement.....I would really like to cut down on some of the looooong names like the new zip functions. Can we agree on, that when we map a function that could be/are in a standard library we prefix a "x" like xmalloc(), xzipopen() etc. > > In my previous mail I really just wanted to point out that by itself, this > doesn’t really solve anything - the issue is in reality far more > complicated than a simple NULL pointer check. > > I can think of two ways we could deal with the issue of graceful handling: > > 1) Allow the application to supply a callback, as Jan suggested > +1 For now let us just declare a function pointer which statically point to a function in DocFormats, and then move that out when we get around to do the API. > 2) Adopt a “memory pool” type strategy where we create an memory pool > object at the start of conversion which tracks all allocations that occur > between the beginning and end of a top-level API call like DFGet, and put > setjmp/longjmp-style exception handling in these API calls. > I am all in for that....but 1 step at a time, lets first have the central function, and then do the memory pool. I would like to discuss this item later in a bit more detail. One option I have used a lot is to use "semantic malloc/free", meaning the caller supplied an ID with the malloc request, so we can cleanup all xmalloc with that ID and leave the rest. > The second approach is in fact already used to a limited extent with the > DOM API. Every document maintains its own memory pool for storing Node > objects (and the text values of nodes)… this is freed when the document’s > retainCount drops to zero. I did this because it was much faster than > traversing through the tree and releasing nodes individually (at least in > comparison to have nodes as Objective C objects - the ObjC runtime was > undoubtedly part of that overhead). > When we have the callback that might be easier and cleaner to use. rgds jan i. > > — > Dr Peter M. Kelly > [email protected] > > PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > >
