If I attempt an asynchronous write using OS.File.writeAtomic in a quit-application-requested observer, is there a possibility that the write will fail, since the observer will return before the write is completed, and the shutdown will continue?
Is the OS.File API preserved until all promises are kept, or is it possible for the shutdown to destroy it while there is still an unfulfilled promise?
Good q i asked this as well on stackoverflow and the answer was it can fail so you should use something that blocks like nsIFile. Ill try to dig ou that topic. But in the mean time use nsIFile for sure.
However if your thing blocks for more then 60 seconds, then firefox will be force quit. That doesnt apply to just your specific thing, but if the shutdown process in general, it is allowed 60sec, after that it force quits.
Thanks. I was hoping to avoid nsIFile, since it is apparently deprecated in favor of OS.File. I hope OS.File will come up with a synchronous file read/write. Sometimes you just need to have a blocking file I/O.
Another thing I haven’t found a way to do with OS.File is to get a directory listing, analogous to:
nsIFile.directoryEntries
The 60 second thing is good to know.
I think if we need to use OS.File sync, then we should spawn a ChromeWorker, I actually try to do all my OS.File stuff in a ChromeWorker, because on the main thread, all OS.File actions use a shared instance of OS.File. In workers we get our own dedicated OS.File instance.
Maybe someone else would know, if we spawned on quit of firefox a ChromeWorker to do some OS.File work, would it hopefully block Firefox till the OS.File work is complete?
That sure is a lot more work. This all used to be a lot simpler with nsIFile, as far as sync goes anyway. It just sure would be nice if sync IO could be part of the OS.File module.
AsyncShutodwn.jsm
thats it, that will do all your stuff before shutdown. and if it doesnt finish before 60sec are up i think it will happen later im not sure.
Nice find, thank you.
Credit to @yoric for that one.
Please post up how you use it, i haven’t had a chance to mess with it so seeing your example would be awesome.
After 60 seconds, your computer blows up 
More seriously, after 60 seconds, we get a crash report telling us what prevented shutdown, so that we can fix the bug.
Hahaha, disks spin, but thankfully mine doesn’t blow! What usually keeps mine alive is my dev work stuff so hopefully I’m not filling up your guys stuff with crash reports.
What about if there was left of work registed with AsyncShutdown.jsm (probably super edge case) during that forced quit/crash report? Does that ever get completed?
Well, once we have crashed, nothing gets completed.
On the other hand, I have never seen stuff that needs 60 seconds to complete during shutdown. We have statistics that tell us that, in practice, no individual task takes more than 2 seconds, so with 60 seconds, you should have ample time to finish. Note that we may lower the 60 seconds to 10 seconds in the future, since in practice nobody uses these 60 seconds.