2013.08.02 08:04 "Re: [Tiff] memory management function calls", by Chris Liddell

2013.09.04 07:56 "Re: [Tiff] memory management function calls", by Chris Liddell

On 03/09/13 19:53, Frank Warmerdam wrote:

  Chris,

I haven't replied because I don't see much need for this. The only situation I have seen where something like this might be useful is the Postgresql pool allocator where once a transaction is complete all allocations related to it are force-freed.

In Ghostscript we have a similar "fail safe" setup, where when a Ghostscript instance is destroyed, all the memory managed by that instance is "force-freed". Obviously, it's not something we like to rely on, but it's there as a last ditch.

In truth, our requirement doesn't really relate to that, and is, perhaps, stretching things with libtiff a little.

We have Ghostscript ports "out there", mainly embedded, but not all, on systems that, for one reason or another, Ghostscript cannot use the "normal" c-library heap memory manager, but must use another, custom memory manager. In some cases, this is because the system maintains custom memory pools for separate tasks, in others it's simply because the stock memory management implementation is quite slow for certain patterns of use.

For that reason, we have a policy that whenever possible, third party libraries should be integrated in such a way as to use the GS memory manager.

So far, we've not had a problem with libtiff, because none of those ports have required tiff output, so we could just disable it (or tell them to disable it).

I'm not keen on the change, but I'm not necessarily fighting it.

Well, I'd be unsurprised to see (and half expect) the patch rejected.

As I see it, by design or by coincidence, libtiff currently allows for file i/o and error/warning reporting to be "hooked", it seems a shame not to "complete the set" by allowing memory management hooks, too.

Chris