Hi,
PLDHashTable, nsTHashtable, and all their subclasses require a
*capacity* to be specified when they are created. If the given
capacity is not a power-of-two, it is rounded up to the next highest
power-of-two. A table with a given capacity can hold at most
0.75*capacity elements, and the
On Tue, Aug 5, 2014 at 1:09 AM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote:
Yes, that's correct. You have to clear them somehow before the
process exits or we leak.
Which, besides accounting, is not really a problem, since the process is
On 2014-08-06, 1:32 PM, Benjamin Smedberg wrote:
On 8/6/2014 1:20 PM, Chris Peterson wrote:
I don't understand this sentence, but I strongly oppose automatically
clearing Static*Ptr in the static destructor in any build. In the past
we have had static comptr cause final release of objects
On 8/8/2014 11:25 AM, Ehsan Akhgari wrote:
The problem I was mentioning is not related to the leak at all. What
if one of these destructors runs code that writes something to the
disk for example, which we expect to go to the disk before we shut down?
Then we should assert in debug builds!
On 2014-08-08, 11:42 AM, Benjamin Smedberg wrote:
On 8/8/2014 11:25 AM, Ehsan Akhgari wrote:
The problem I was mentioning is not related to the leak at all. What
if one of these destructors runs code that writes something to the
disk for example, which we expect to go to the disk before we
- Original Message -
OK, I guess that's better than what we have now... Still I thought the
goal of this class is to avoid static initializers, so why do we want a
trivial destructor for it in release builds?
So the compiler won't generate a static initializer that ensures the
On 2014-08-08, 12:20 PM, Nathan Froyd wrote:
- Original Message -
OK, I guess that's better than what we have now... Still I thought the
goal of this class is to avoid static initializers, so why do we want a
trivial destructor for it in release builds?
So the compiler won't generate
FYI - some significant network work will be performed during our regular
Tree Closing Window (TCW) Saturday, Aug 9, 0900-1200 PT (details below)
We are going to not formally close the trees, but there will likely be
delays (from auto retry) and some jobs might need to be manually
retriggered.
On Friday 2014-08-08 11:25 -0400, Ehsan Akhgari wrote:
The problem I was mentioning is not related to the leak at all.
What if one of these destructors runs code that writes something to
the disk for example, which we expect to go to the disk before we
shut down?
User-visible actions should
9 matches
Mail list logo
