[boost] Re 6. Re: Re: Query of Interest - vlarray (David White)

From: hicks (hicks_at_[hidden])
Date: 2002-04-18 13:55:58

 Re 6. Re: Re: Query of Interest - vlarray (David White)

- I don't think seperate storage is necessary (see below).
- I meant to suggest that one might want to allow heap objects to use
the stack as well.
Suppose the heap object belongs to an auto_ptr which is itself on the
stack, but
the order of destruction inside the object it not the same as the order
of construction,
(even if just because the code got written that way and I'm too busy to
fix it for
appearances sake now).
- I also meant to suggest that out of order destruction might otherwise
be desirable.
Suppose you want the functionality to resize a psuedo-valarray array
size. Then you have
to "free" a block not at the end of the stack, and allocate a new block
which will be freed
after the others that come before it.
- I did not mean to suggest that mutex's would have any use for
psuedo-valarray.
I asked about the relative costs of (a) a mutex call compared to
(b) a heap allocation call. I asked this thinking that if one was
dissatisfied
with heap allocation performance, and one knew these relative costs, and
if (a) the
mutex call was much more expensize than (b) overall, then simply
changing to a thread
specific heap might be enough to achieve satisfactory performance
improvement.
Really, I wish there were a standard pair of calls: thread_new and
thread_delete.
I think it's the exception rather than the rule to create objects which
need to be deleted
in a different thread. In general, I find the tendency for libraries
(e.g., strings, streams)
to contain secret mutexes rather awful. (At least we should have the
option of choosing.)
- I do agree with you about forcing errors if usage was not as intended.
If you intend to
all LIFO only then it should be so.

- How to implement a blocklist with using memory outside the stack
I would suggest one of 2 things:
1.Put a 32K limit on the block size, and store a short
just beyond the bottom of every allocated block.
In that short, the top bit would indicate "free",
and the other 15 would give the size.
2. The same thing with a 128 byte limit and a byte at the end of
every block.
Then the list could be traversed backwards begging from the stack end
pointer,
and no seperate storage (outside of the stack) would be required.