storage/mozIStorageVacuumParticipant.idl
author Nicholas Nethercote <nnethercote@mozilla.com>
Fri, 16 Feb 2018 17:54:16 +1100
changeset 407868 32d6774930e55be5c03e8d631fc067a995623c1e
parent 244681 ad01543457e739b4eee7a245e16734a3ecfd10ad
permissions -rw-r--r--
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
 * vim: sw=2 ts=2 et lcs=trail\:.,tab\:>~ :
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

#include "nsISupports.idl"

interface mozIStorageConnection;

/**
 * This interface contains the information that the Storage service needs to
 * vacuum a database.  This interface is created as a service through the
 * category manager with the category "vacuum-participant".
 * Please see https://developer.mozilla.org/en/mozIStorageVacuumParticipant for
 * more information.
 */
[scriptable, uuid(8f367508-1d9a-4d3f-be0c-ac11b6dd7dbf)]
interface mozIStorageVacuumParticipant : nsISupports {
  /**
   * The expected page size in bytes for the database.  The vacuum manager will
   * try to correct the page size during idle based on this value.
   *
   * @note If the database is using the WAL journal mode, the page size won't
  *        be changed to the requested value.  See bug 634374.
   * @note Valid page size values are powers of 2 between 512 and 65536.
   *       The suggested value is mozIStorageConnection::defaultPageSize.
   */
  readonly attribute long expectedDatabasePageSize;

  /**
   * Connection to the database file to be vacuumed.
   */
  readonly attribute mozIStorageConnection databaseConnection;

  /**
   * Notifies when a vacuum operation begins.  Listeners should avoid using the
   * database till onEndVacuum is received.
   *
   * @return true to proceed with the vacuum, false if the participant wants to
   *         opt-out for now, it will be retried later.  Useful when participant
   *         is running some other heavy operation that can't be interrupted.
   *
   * @note When a vacuum operation starts or ends it will also dispatch a global
   *       "heavy-io-task" notification through the observer service with the
   *       data argument being either "vacuum-begin" or "vacuum-end".
   */
  boolean onBeginVacuum();

  /**
   * Notifies when a vacuum operation ends.
   *
   * @param aSucceeded
   *        reports if the vacuum succeeded or failed.
   */
  void onEndVacuum(in boolean aSucceeded);
};