author Jim Blandy <jimb@mozilla.com>
Tue, 12 Feb 2019 08:16:16 +0000
changeset 458932 414b2c238839c321dee78a9d927c968f1e52ae79
parent 454520 5f4630838d46dd81dadb13220a4af0da9e23a619
permissions -rw-r--r--
Bug 1145201: Replace EnqueuePromiseJobCallback and GetIncumbentGlobalCallback with new JobQueue abstract base class. r=arai,smaug While the behavior of ECMAScript Promises and their associated job queue is covered by the ECMAScript standard, the HTML specification amends that with additional behavior the web platform requires. To support this, SpiderMonkey provides hooks the embedding can set to replace SpiderMonkey's queue with its own implementation. At present, these hooks are C-style function-pointer-and-void-pointer pairs, which are awkward to handle and mistake-prone, as passing a function the wrong void* is not a type error. Later patches in this series must add new hooks, making a bad situation worse. A C++ abstract base class is a well-typed alternative. This introduces a new `JS::JobQueue` abstract class, and adapts SpiderMonkey's internal job queue and Gecko's customization to use it. `GetIncumbentGlobalCallback` and `EnqueuePromiseJobCallback` become virtual methods. Within SpiderMonkey, the patch gathers the various fields of JSContext that implement the internal queue into their own type, js::InternalJobQueue. Various jsfriendapi functions become veneers for calls to methods specific to the derived class. The InternalJobQueue type itself remains private to SpiderMonkey, as it uses types like TraceableFifo, derived from Fifo, that are not part of SpiderMonkey's public API. Within Gecko, CycleCollectedJSContext acquires JS::JobQueue as a private base class, and a few static methods are cleaned up nicely. There are a few other hooks defined in js/public/Promise.h that might make sense to turn into virtual methods on JobQueue. For example, DispatchToEventLoopCallback, used for resolving promises of results from off-main-thread tasks, is probably necessarily connected to the JobQueue implementation in use, so it might not be sensible to set one without the other. But it was left unchanged to reduce this patch's size. Differential Revision: https://phabricator.services.mozilla.com/D17544

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set sw=2 ts=8 et ft=cpp : */
/* 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/. */

#ifndef mozilla_HalInternal_h
#define mozilla_HalInternal_h 1

 * This file is included by HalImpl.h and HalSandbox.h with a mechanism similar
 * to Hal.h. That means those headers set MOZ_HAL_NAMESPACE to specify in which
 * namespace the internal functions should appear.
 * The difference between Hal.h and HalInternal.h is that methods declared in
 * HalInternal.h don't appear in the hal namespace. That also means this file
 * should not be included except by HalImpl.h and HalSandbox.h.

#  error "You shouldn't directly include HalInternal.h!"

namespace mozilla {

 * Enables battery notifications from the backend.
void EnableBatteryNotifications();

 * Disables battery notifications from the backend.
void DisableBatteryNotifications();

 * Enables network notifications from the backend.
void EnableNetworkNotifications();

 * Disables network notifications from the backend.
void DisableNetworkNotifications();

 * Enables screen orientation notifications from the backend.
void EnableScreenConfigurationNotifications();

 * Disables screen orientation notifications from the backend.
void DisableScreenConfigurationNotifications();

 * Has the child-side HAL IPC object been destroyed?  If so, you shouldn't send
 * messages to hal_sandbox.
bool HalChildDestroyed();
}  // namespace MOZ_HAL_NAMESPACE
}  // namespace mozilla

#endif  // mozilla_HalInternal_h