Autor: Philip Hazel Data: Para: Graycode CC: pcre-dev Assunto: Re: [pcre-dev] [Bug 1174] allow passing of pcre_{malloc, free,
stack_malloc, stack_free, callout} as parameters
On Wed, 9 Nov 2011, Graycode wrote:
> It seems I may have misunderstood the issues at hand because of my
> unfamiliarity with the technical meaning of "installed as a shared
> library". If that kind of library installation would share a single
> instance of the library's live data across multiple programs then
> that's beyond my ability to comprehend or suggest a safe solution.
My understanding is that a shared library shares the *code* across
multiple programs, but each address space (in Unix, each process) gets
its own copy of any static data. I also assume that multiple threads
within one process share heap data, but each thread has its own stack.
I've written multi-process programs - e.g. Exim - but I have never had
to tangle with threads; hence my relative ignorance about how they work.
> Your idea sounds good, and I must appologise because I thought that
> PCRE had storage variables (which I referred to as statics) for
> configuration data such as the match_limit. In reviewing the code,
> that is not currently the case.
This is to make it thread-safe. Once upon a time, up to release 0.94
(September 1997), it did have many more static variables, but that was
changed as soon as a thread user pointed out the problem, except that I
left the function pointers for memory management, assuming (probably
stupidly) that different threads would not want different versions of
them.
The issue of other libraries using PCRE is a new one that has only just
come to my attention. It means that, even within one thread, different
parts of the application may need to use different memory management
functions.
> Below is a representation of the kind of app_config() that I suggested.
> But without PCRE having storage variables for some of the options,
> the utilization of the concept is limited to the storage represented by
> the memory allocation / free vectors. In this illustration I'm
> suggesting two functions: One that populates the current configuration,
> and another that modifies it.
PCRE is not, of course, an "app", and it really should not have any
storage of its own. One possibility is for there to be some kind of
structure, in storage controlled by the caller, that contains all the
relevant parameters. A pointer to this could be passed to every PCRE
function, and there could be functions to manipulate its contents.
> Our threads that use PCRE are created using only 32K
> total stack size. That's probably your worst-case scenario but PCRE
> has been able to do the job. Please pat yourself on the back.
Wow. That's nice to know. Thanks.
As you may have read in another thread, I'm going to write a document
that tries to cover a number of major issues that are being discussed,
to try to lay out what our options are.
