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 shoul
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.
P
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
- 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
non-
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 shu
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-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 aft
On Tue, Aug 5, 2014 at 1:09 AM, Mike Hommey 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
> exiting
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 averag
9 matches
Mail list logo