Re: Are StaticAuto/RefPtr good?
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 never be in destructors, except for RAII classes, because having a complex system with garbage collection and potentially with leaks means that we can't guarantee when destructors will run. Destructors should (transitively) contain only things that wouldn't be there if we were writing in a higher level language that did memory management for us. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FYI: [Planned Maintenance Notification] August 9th - Tree Closing Maintenance Window
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. Please take this into consideration, and be prepared to do extra monitoring of any jobs you start which will be active during the TCW. Thanks! Original Message Subject:[Planned Maintenance Notification] August 9th - Tree Closing Maintenance Window Date: Fri, 08 Aug 2014 17:49:32 - From: m...@mozilla.com To: infra-...@mozilla.com Short Summary: Mozilla IT will have a network maintenance window on Saturday, August 9th, from 0900-1200 PDT. During this window we will be implementing network improvements to improve long-term stability and performance in both our PHX1 and SCL3 datacenters. Brief network interruptions and reduced network performance may be experienced during this window. 1048340 - master tracking bug 1046119 - complete removal of graceful-restart 1046122 - complete next-hop-self project 1046123 - delete the deprecated group from fw1.releng.scl3 1046129 - remove 63.245.214.0/23 from fw1.scl3 to border[12].scl3 1046132 - remove default routes from border routers after next-hop-self project is complete 1046133 - delete unused static routes for decomm'ed data centers 1046136 - remove load-balancing from network configurations Mozilla IT Outage Notification: -- Issue Status: Upcoming Bug IDs: 1048340 Start Date:2014-08-09 Start Time:09:00 PDT Site: All datacenters Services: Impact of Work:Brief network interruptions and reduced network performance for services hosted in the SCL3 and PHX1 datacenters. If you have any questions or concerns please address them to incide...@mozilla.com -- m...@mozilla.com - m...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
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 a static initializer that ensures the non-trivial destructor is called at shutdown. See bug 809931. Bad bad compiler, look what you've done!!! OK, I retract my earlier comment then. :/ Thanks for the reference. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
- 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-trivial destructor is called at shutdown. See bug 809931. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
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 shut down? Then we should assert in debug builds! Perhaps we should even assert that such pointers are cleared by the end of XPCOM-shutdown, although that's more complexity. We will have already shut down XPCOM and the profile will be unlocked, so it is very likely that in such a scenario the write will succeed, go to the correct place, or not be a risk of dataloss. 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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
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! Perhaps we should even assert that such pointers are cleared by the end of XPCOM-shutdown, although that's more complexity. We will have already shut down XPCOM and the profile will be unlocked, so it is very likely that in such a scenario the write will succeed, go to the correct place, or not be a risk of dataloss. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
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 after XPCOM shutdown, which causes crashes due to the component manager or CC or other infrastructure already being shut down. Wouldn't that be a bug that should be fixed? Sure, it's a leak bug that should be fixed. But since figuring out whether a late release will cause a crash or a security issue or is harmless is hard, it's better to assert in debug builds and leak in release builds than to clear in release builds. So far I don't think anyone has proposed crashing in release builds, which I don't think is worth the risk. 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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
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 anyways. It can be a problem if desctructor code is actively > doing import stuff like persisting state. And it may be worth pointing out that calling lots of destructors could in principle slow down shutdown -- which also means slowing down restart, I assume. I don't know if that's a real problem for us, but I once heard a MySQL dev remark that MySQL restart was at the time significantly slowed down by lots of free()s whose only purpose in life was to make valgrind happy. So I thought it was worth pointing out. (IIRC, MySQL is written in C, so the correctness issue of not running destructors was not applicable to them.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PLDHashTable and nsTHashtable are now initialized with a length rather than a capacity
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 average table will hold 0.5*capacity elements. However, it's clear that lots of people thought that the initial value given upon creation was a *length* rather than a *capacity*, i.e. indicates how many elements the table will contain. For example, there were dozens of places where a hash table was created and initialized by inserting elements from a fixed-length list with length N, but the specified capacity was also N, which means the table will have to be resized (and rehashed) along the way. Therefore, in bug 1050009 I changed things so that the given value is a length rather than a capacity. This means these types are now consistent with js::HashTable. I audited every place a hash table was created and adjusted the parameter appropriately. Finally, for PLDHashTable, the length parameter is now an optional parameter. (It was already optional for nsTHashtable and its subclasses.) Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
