Re: OS.File and shutdown

[David Rajchenbach-Teller]

On 5/13/13 10:20 PM, David Rajchenbach-Teller wrote:
> On 5/10/13 10:45 PM, Felipe Gomes wrote:
>> Hi, does OS.File guarantees that write tasks that have started will be 
>> completed if a shutdown occurs? My use case is for writeAtomic but I'm 
>> interested about the behavior of both write and writeAtomic.
>> Corner case: what if I call write/writeAtomic from an xpcom-shutdown 
>> observer?
> 
> In theory:
> - every call to OS.File queued *before* xpcom-shutdown will be completed;
> - every call to OS.File queued after xpcom-sthudown will throw an
> asynchronous exception (once bug 845190 has landed).

Actually, what I wrote was misleading. Calls to OS.File queued during
xpcom-shutdown will be honoured *if the OS.File thread has already been
initialized* before xpcom-shutdown – this is the case in Firefox itself,
but not necessarily in xpcshell tests.

Cheers,
 David

-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dropping support for building with MSVC2005/2008

[Ehsan Akhgari]

Hi all,

Over in bug 866425, we're planning to drop support for MSVC2005/2008.
MSVC2010 and MSVC2012 will remain supported compilers for Windows.

Previously there was no free (as in beer) version of MSVC2010 so we had to
support those older compilers to make it possible to build Mozilla with a
free build environment, but MSVC2010 Express is now freely available, and
there is no good reason to keep supporting those old compilers any more.

Note that this patch just makes configure be explicit about our implicit
policy.  Over the past few years we've been consistently breaking those old
compilers, which meant the users of those compilers were in constant pain
when a new change broke their build.  Those users should upgrade to
MSVC2010 now, in order to enjoy a supported build environment.

This change will only affect mozilla-central, and will ride the trains as
any other change would.

Cheers,
--
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dropping support for building with MSVC2005/2008

[Ehsan Akhgari]

This just landed on mozilla-inbound.

--
Ehsan



On Tue, May 14, 2013 at 10:45 AM, Ehsan Akhgari wrote:

> Hi all,
>
> Over in bug 866425, we're planning to drop support for MSVC2005/2008.
> MSVC2010 and MSVC2012 will remain supported compilers for Windows.
>
> Previously there was no free (as in beer) version of MSVC2010 so we had to
> support those older compilers to make it possible to build Mozilla with a
> free build environment, but MSVC2010 Express is now freely available, and
> there is no good reason to keep supporting those old compilers any more.
>
> Note that this patch just makes configure be explicit about our implicit
> policy.  Over the past few years we've been consistently breaking those old
> compilers, which meant the users of those compilers were in constant pain
> when a new change broke their build.  Those users should upgrade to
> MSVC2010 now, in order to enjoy a supported build environment.
>
> This change will only affect mozilla-central, and will ride the trains as
> any other change would.
>
> Cheers,
> --
> Ehsan
> 
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS.File and shutdown

[Felipe Gomes]

On Friday, May 10, 2013 7:53:01 PM UTC-3, Benjamin Smedberg wrote:
> I'm not sure about the rest of this question. But you should not be 
> 
> performing any I/O after profile-before-change. See 
> 
> https://wiki.mozilla.org/XPCOM_Shutdown and note that after 
> 
> profile-before-change, we are working on immediately exiting the browser 
> 
> and skipping XPCOM shutdown. xpcom-shutdown is definitely too late!

Okay. The code i'm touching does that on xpcom-shutdown but since it'll be 
wrong in the future I'll change it while I'm there. (it finishes some pending 
async sqlite stmts and rolls back any ongoing transactions).


What prompted the question is that I'm working on a conversion from SQLite 
storage to a JSON file. OS.File.writeAtomic provides a good guarantee of data 
consistency against crashes etc, and I'm now looking how to guarantee a proper 
full flush of the data to disk during shutdown.

Should profile-before-change then be my call to stop accepting changes to the 
data and call writeAtomic to flush it? I've seen some code nearby doing it at 
quit-application-granted. Or perhaps there's no "correct" answer and it varies 
case by case (or anything goes that works and is early enough..)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink meeting: Today May 14, 2013 @ 2:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by leaky(?) offscreen 
surfaces in Windows:
https://bugzilla.mozilla.org/show_bug.cgi?id=869252

The wiki page for this meeting is at:

   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 14 May 2013, 2:00 PM PDT
* Vidyo: MTV 3V Very Good Very Mighty
* MTV: PB&J, Mountain View office, 3rd floor.
* SF: Bay Bridge, San Francisco office, 3rd floor.
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 95346

--Jet
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS.File and shutdown

[Gregory Szorc]

On 5/14/13 11:35 AM, Felipe Gomes wrote:

On Friday, May 10, 2013 7:53:01 PM UTC-3, Benjamin Smedberg wrote:

I'm not sure about the rest of this question. But you should not be

performing any I/O after profile-before-change. See

https://wiki.mozilla.org/XPCOM_Shutdown and note that after

profile-before-change, we are working on immediately exiting the browser

and skipping XPCOM shutdown. xpcom-shutdown is definitely too late!


Okay. The code i'm touching does that on xpcom-shutdown but since it'll be 
wrong in the future I'll change it while I'm there. (it finishes some pending 
async sqlite stmts and rolls back any ongoing transactions).


What prompted the question is that I'm working on a conversion from SQLite 
storage to a JSON file. OS.File.writeAtomic provides a good guarantee of data 
consistency against crashes etc, and I'm now looking how to guarantee a proper 
full flush of the data to disk during shutdown.

Should profile-before-change then be my call to stop accepting changes to the data and 
call writeAtomic to flush it? I've seen some code nearby doing it at 
quit-application-granted. Or perhaps there's no "correct" answer and it varies 
case by case (or anything goes that works and is early enough..)


This sounds very similar to what I ran into with Firefox Health Report.

There is some discussion in 
https://bugzilla.mozilla.org/show_bug.cgi?id=722648 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=850712.


Generally speaking, you have a queued async operation or set of async 
operations that need to complete. However, profile-before-change is 
observed before or during those operations. There is a race between 
xpcom-shutdown and those async operations finishing.


FHR's solution to this problem is to initiate the shutdown procedure 
early during shutdown. We chose quit-application. If this shutdown 
sequence (which consists of waiting for async operations initiated or 
queued before shutdown started) has not completed by the time 
profile-before-change (the last observer before the profile goes away) 
is observed, FHR creates a nested event loop during the 
profile-before-change handler. This delays shutdown. But it eliminates 
race conditions and prevents data corruption. Code at 
https://hg.mozilla.org/mozilla-central/file/26ab72bfa9df/services/healthreport/healthreporter.jsm#l445


Performance *really* doesn't like this solution because it can delay 
shutdown. However, the last I checked Telemetry, we only had 121 reports 
on Nightly and Aurora of this occurring in the past month. This is 
because we only create a nested event loop if shutdown hasn't finished 
by profile-before-change and unless a major FHR operation was initiated 
just before shutdown, there will be no work to do except close the 
database handle. If we were buffering data and persistently flushing, 
we'd likely be spinning much more since we'd be more likely to have 
queued I/O.


I'll conclude by saying that every scenario is different. I highly 
recommend you connect with someone on the Perf team for a tailored 
recommendation.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: converting CPPSRCS to moz.build

[Mike Shal]

On Mon 13 May 2013 04:17:39 PM EDT, Ryan VanderMeulen wrote:

On 5/13/2013 4:08 PM, Ehsan Akhgari wrote:

I don't see the downside of a very short tree closure.  It is our common
way of doing large scale stuff like this across the codebase.



Agreed, no sense in tempting fate. Besides, 6am PT is a time where
there's both good sheriff coverage and low activity. Seems like the
right time to do it to me.


Unfortunately this patch isn't ready yet. I'll have to postpone until 
another day :(.


-Mike

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform