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. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
