Re: [Lcms-user] Default memory allocation functions

[<mar...@li...>]

Hi Robin,

Regarding this 2nd part:

>As far as I can see this code still ends up redirecting through a set
>of static variables that hold function pointers.

Right, and this is done on this way on purpose. The library is 
"instance agnostic" in the sense it is not aware of itself being 
instanciated more than once. I did it in such way for simplicity 
sake. Sure, I could use some sort of context to store plug-in 
info and make several instances of the library each one using 
different plug-ins. 
But that would make things unnecessarely complex for casual 
users, and at the end I think plug-ins are an exception instead 
of a rule. So, in order to simplify developement, plug-ins 
are shared between instances, which seemed reasonable at the 
time, since plug-ins are  mostly a way to expand the engine. 
Those that want to use private plug-ins can link statically 
and everybody would be happy.

Now I see there is no way to make everybody happy, specially 
when one deals with programming :-)

Anyway, still I cannot see why do you need a way to redefine 
default memory handlers. If you link statically, you can add 
a plug-in as well and it would take about 10 lines of code. 
See the example below. On the other hand, if you are linking 
dynamically you can't modify the default allocators anyway.
Probably I'm missing something, maybe you don't want malloc 
being linked in your code to avoid dependencies?

> I wonder if a better solution would not be to simply expose
>_cmsRegisterMemHandlerPlugin (or something like it) to the outside
> world. This would enable non-plugin callers to provide their own
> malloc/realloc/free functions.

That is exactly how it works. See the plug-in documentation, it 
explains how to do it. See "Memory management plug-in" on page 11.

Example
-------
cmsPluginMemHandler MemHandler = {{ 
                                   cmsPluginMagicNumber, 
                                   2000,  
                                   cmsPluginMemHandlerSig, 
                                   NULL 
                                  }, 
                                  my_malloc, 
                                  my_free, 
                                  my_realloc, 
                                  NULL, 
                                  NULL, 
                                  NULL };


cmsPlugIn(&MemHandler);
-------

And that is all you need. Hope that helps.

Cheers. Regards to Miles and Michael Vhrel if you see them :-)
Marti Maria.

Original Message:
-----------------
From: Robin Watts Rob...@ar...
Date: Tue, 05 Apr 2011 00:07:02 +0100
To: lcm...@li...
Subject: [Lcms-user] Default memory allocation functions


Gents,

Part 2 of the changes fed back from my experiments with making
Ghotscript work with lcms v2.

As far as I can see, there exists no way within the current API to
avoid the memory functions using malloc and free (unless you are
implementing a plugin, which we are not).

Lcms v2 appears to have gained some changes in this area over v1 that
are, I think, intended to allow different plugins to use different
families of allocation functions.

As far as I can see this code still ends up redirecting through a set
of static variables that hold function pointers. As such attempting
to use a single library instantiation simultaneously from multiple
different plugins will fail?

This is, currently at least, not a problem for us, however as we
statically link against a library and are hence sure that we will be
the only callers at a time.

The attached patch is a simple change that follows the approach we
took for lcms v1. If we define 'CMS_USER_ALLOC' when the lib is
built, we get to define cms{Malloc,Realloc,Free}DefaultFn, and the
library will link and use those.

This is working locally, and seems a relatively non-invasive change
to your library.

Thinking about again however, while writing this email, I wonder if a
better solution would not be to simply expose
_cmsRegisterMemHandlerPlugin (or something like it) to the outside
world. This would enable non-plugin callers to provide their own
malloc/realloc/free functions.

It would leave the library depending on malloc/realloc/free, but
they'd never be called. I suspect this is unlikely to ever be a
serious issue.

Thanks for your time and effort in creating a great library.

Robin
-- 



--------------------------------------------------------------------
mail2web.com - Microsoft® Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange