Open Bug 1915213 Opened 1 month ago Updated 18 days ago

Add an async flush method to nsToolkitProfileService

Categories

(Toolkit :: Startup and Profile System, enhancement)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: jhirsch, Assigned: niklas)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

As part of the work to enable multiple concurrent Firefox instances to write to profiles.ini in bug 1893867, we will need to make an async version of the Flush() method. Our new method will need to coexist with the existing non-async Flush(), whether that's refactoring the core code out to a FlushInternal() called by both, or checking the build flag to decide whether to run sync or async, or something else, I'm not sure.

Because the profile service is callable from JS, we'll need to modify the nsIToolkitProfileService IDL to add our new method (FlushAsync? idk) that returns a Promise (this is an XPIDL type), and the implementation will return a dom::Promise. However, actually implementing the async behavior may be simpler using C++-only MozPromise.

There is a separate bug XXXXXXX [TODO: file and insert bug number] to figure out how to manage write contention for profiles.ini through some kind of filesystem locking. While we can't test that specific async behavior in this bug, since the two are parallel bugs, we could perhaps create a no-op placeholder "get the file lock" method in this bug, something that waits a few milliseconds then sets a bool "mProfilesIniWriteLock" to true, simulating our instance getting an nsProfileLock on the file. If we make such a bool available to check, I think (not sure) we could use SpinEventLoopUntil to handle repeatedly checking the bool's value, then resolving the MozPromise when it becomes true.

It is not possible to use ifdefs in IDLs, so we will need to follow the approach taken in other patches, like SetRootDir, where we add a new method to the IDL, but use an ifdef inside the implementation that throws an error if the MOZ_SELECTABLE_PROFILES build flag is false.

Assignee: nobody → nbaumgardner
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: