[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Static pools?

From: Matthew Hambley <matthew_at_aether.demon.co.uk>
Date: 2003-03-08 19:17:51 CET

In message <5F32C383-518B-11D7-BF62-000393CE23F4@electricjellyfish.net>
          Garrett Rooney <rooneg@electricjellyfish.net> wrote:

> On Saturday, March 8, 2003, at 12:09 PM, Matthew Hambley wrote:
>
> > I want a block of memory which will last across calls to a function.
> > i.e. a static, global to my source file. How do I go about achieving
> > this with the memory pool system used by APR? Presumably I can't
> > simply say:
> >
[snip]
> let's ask a better question. why do you want to allocate a bunch of
> static memory? static memory like that is generally a "bad thing"
> (tm), especially from a thread safety point of view.

Simple. I want to create a mapping table which needs to exist between
calls to the interrogation function. This involves parsing a file. I
could parse the file every time the data needs to be interrogated (and of
course that is what I will need to do if there isn't space to build the
table) but that would require a lot of file access and a lot of time.
Better to do it as infrequently as possible.

Thinking OO for a moment, what I want is a static member variable.

> if you absolutely posetively without a doubt HAVE to do it, you could
> create a new pool (with no parent) inside your first run block, and
> allocate out of there... or you could hang it off the global pool like
> we do for apr_xlate structures (but that's evil, and we want to stop
> doing that).

However it looks like there isn't a clean way to achieve this so I may have
to go for maximum inefficiency anyway.

-- 
(\/)atthew )-(ambley ---------------\ If something's worth doing it's worth
E-mail : matthew@aether.demon.co.uk  \ doing badly until you can learn to
Public key : C991137B                 \ do it well.
Web : http://www.aether.demon.co.uk/   \-----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 8 19:19:26 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.