|
Home > Archive > Unix Programming > June 2005 > How to use obstack
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to use obstack
|
|
| Zheng Da 2005-06-27, 2:49 am |
| I have read "inside memory management", and know there is a technology
called obstack.
I read the info of obstack, but do not understand well.
For example, I do not know where obstack will be used, where it
shouldn't be used; and how obstack works.
By the way, there is Growing Objects in obstack, and I didn't
understand after I read the info about it.Is there anyone give an
example about the growing objects?
Thank you.
| |
| Andrei Voropaev 2005-06-27, 7:55 am |
| On 2005-06-27, Zheng Da <zhengda1936@gmail.com> wrote:
> I have read "inside memory management", and know there is a technology
> called obstack.
> I read the info of obstack, but do not understand well.
> For example, I do not know where obstack will be used, where it
> shouldn't be used; and how obstack works.
> By the way, there is Growing Objects in obstack, and I didn't
> understand after I read the info about it.Is there anyone give an
> example about the growing objects?
Obstack is somewhat similar to automatic variables allocated on the
stack. After you leave the function all the auto variables automatically
disappear. So obstack might be good for "staged" things. For example,
you get a request from user. For processing of this request you need
memory, but only for processing. So you allocate the memory as an
obstack, then you get smaller chunks of memory from that obstack. When
you are done with the request, you deallocate the whole obstack, not
thinking about every single little chunk that you've allocated from it.
Frankly speaking, I've never used obstack myself, because its usage is
so specific. Usually the objects have to stay for long, and usually any
temporary storage is easier to allocate on the stack.
--
Minds, like parachutes, function best when open
| |
| Zheng Da 2005-06-27, 5:53 pm |
| It seems one reason to use obstack is to give a way to get an efficient
work to get small chunks.
And it really work like automatic variables allocated on the stack? It
seems the programmer must call obstack_free() to free the whole obstack.
| |
| Michael B Allen 2005-06-28, 2:53 am |
| On Mon, 27 Jun 2005 09:40:17 -0700, Zheng Da wrote:
> It seems one reason to use obstack is to give a way to get an efficient
> work to get small chunks.
> And it really work like automatic variables allocated on the stack? It
> seems the programmer must call obstack_free() to free the whole obstack.
I wrote an allocator called 'suba' [1] that allocates memory from a
larger chunk of memory. One such source of that memory could be stack
memory. Consider the following example:
int
myfn(void)
{
unsigned char chunk[0x3FFF]; /* 16K */
struct allocator *al = suba_init(chunk, 0x3FFF, 1, 0);
Now use allocator_alloc without caring about freeing anything. Just
return. Same idea as obstack but a little more flexible (complex data
structures using shared memory between processes).
Mike
[1] http://www.ioplex.com/~miallen/libm...s/ref/suba.html
Chop off the end of the URL here ^ to get to libmba
| |
| Andrei Voropaev 2005-06-28, 7:50 am |
| On 2005-06-27, Zheng Da <zhengda1936@gmail.com> wrote:
> It seems one reason to use obstack is to give a way to get an efficient
> work to get small chunks.
> And it really work like automatic variables allocated on the stack? It
> seems the programmer must call obstack_free() to free the whole obstack.
It is "kind of" automatic variables. Automatic variables get freed when
you return from function, the obstack can survive the return from the
function and requires explicit free call, but only for the whole
obstack, not for every single chunk you've allocated in it.
As to efficient way to get small chunks... Yes, it is efficient. But not
universal. You can allocate lots of small chunks, but you have to free
them all at once. Basically obstack works by allocating one big chunk of
memory, and then chopping off little chunks from it one by one. It does
not keep track of the chunks, that is why it can't free them. If the big
chunk gets exausted, then another one is added to it and so on.
--
Minds, like parachutes, function best when open
| |
| Jonathan Bartlett 2005-06-28, 5:54 pm |
| > I have read "inside memory management"
For anyone who is interested, the URL is:
http://www-128.ibm.com/developerwor...brary/l-memory/
> I read the info of obstack, but do not understand well.
> For example, I do not know where obstack will be used, where it
> shouldn't be used; and how obstack works.
You should use them when you have a multi-stage operation, where objects
allocated in each stage do not survive past the stage, except where
specified explicitly.
Apache -- uses one pool per connection -- all resources are freed at the
end of the connection
GCC -- used to use obstacks for compilation, and used one obstack per
compilation unit
Samba -- uses one pool per connection
> By the way, there is Growing Objects in obstack, and I didn't
> understand after I read the info about it.Is there anyone give an
> example about the growing objects?
It's just if you don't know how much memory something is going to take
up, you can use a growing obstack to append data to it until you are
finished, and then get its final address.
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
| |
| Zheng Da 2005-06-28, 5:54 pm |
| -- Function: void obstack_grow (struct obstack *OBSTACK-PTR, void
*DATA, int SIZE)
To add a block of initialized space, use `obstack_grow', which is
the growing-object analogue of `obstack_copy'. It adds SIZE bytes of
data to the growing object, copying the contents from DATA.
It seems it grow obstack, not the object, because there is no parameter
which is pointing to an object.
It confuses me much.
| |
| Jonathan Bartlett 2005-06-29, 5:53 pm |
| Zheng Da wrote:
> -- Function: void obstack_grow (struct obstack *OBSTACK-PTR, void
> *DATA, int SIZE)
> To add a block of initialized space, use `obstack_grow', which is
> the growing-object analogue of `obstack_copy'. It adds SIZE bytes of
> data to the growing object, copying the contents from DATA.
>
> It seems it grow obstack, not the object, because there is no parameter
> which is pointing to an object.
> It confuses me much.
>
No, it grows the object, but can only grow an object at the end of an
obstack. From the text you mailed:
"It adds SIZE bytes of data to the growing object"
Since an obstack is a stack, you can't grow the middle elements, but you
can grow the last one. Therefore, obstack_grow doesn't need the pointer
to the object -- it just needs the pointer to the obstack. The last
object is implicit in the obstack.
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
| |
| Zheng Da 2005-06-29, 5:53 pm |
| I know no.
Thank you.
| |
| James Antill 2005-06-29, 5:53 pm |
| On Tue, 28 Jun 2005 08:55:00 -0400, Jonathan Bartlett wrote:
>
> You should use them when you have a multi-stage operation, where objects
> allocated in each stage do not survive past the stage, except where
> specified explicitly.
>
> Apache -- uses one pool per connection -- all resources are freed at the
> end of the connection
> GCC -- used to use obstacks for compilation, and used one obstack per
> compilation unit
> Samba -- uses one pool per connection
It's worth point out that GCC is moving away from obstacks now, as it was
unmanageable ... everything now runs under a GC. Also while pools in
APR/Samba are similar they are different, and provide different APIs (and
I'd say the pool ones are easier to use).
--
James Antill -- james@and.org
http://www.and.org/vstr/httpd
| |
| Jonathan Bartlett 2005-06-30, 6:02 pm |
| > It's worth point out that GCC is moving away from obstacks now, as it was
> unmanageable ... everything now runs under a GC. Also while pools in
> APR/Samba are similar they are different, and provide different APIs (and
> I'd say the pool ones are easier to use).
>
The APIs for APR and Samba pools really aren't all that different from
obstacks. It's just that obstacks have a lot of fairly useless
extensions. But if you stick to a subset of their functions they can be
used in exactly the same manner as the other pool APIs.
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
|
|
|
|
|