mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-22 01:35:35 +00:00
6e40a9dccb
Datastores are preloaded only for content principals. The preloading is triggered as soon as possible to lower the chance of blocking the main thread in content process. If there is no physical database on disk for given origin, datastore is not created. Preloaded datastores are kept alive for 20 seconds.
104 lines
3.7 KiB
Plaintext
104 lines
3.7 KiB
Plaintext
/* 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 protocol PBackground;
|
|
|
|
using struct mozilla::null_t
|
|
from "ipc/IPCMessageUtils.h";
|
|
|
|
namespace mozilla {
|
|
namespace dom {
|
|
|
|
union NullableDatastoreId
|
|
{
|
|
null_t;
|
|
uint64_t;
|
|
};
|
|
|
|
struct LSRequestPrepareDatastoreResponse
|
|
{
|
|
NullableDatastoreId datastoreId;
|
|
};
|
|
|
|
struct LSRequestPrepareObserverResponse
|
|
{
|
|
uint64_t observerId;
|
|
};
|
|
|
|
/**
|
|
* Discriminated union which can contain an error code (`nsresult`) or
|
|
* particular request response.
|
|
*/
|
|
union LSRequestResponse
|
|
{
|
|
nsresult;
|
|
LSRequestPrepareDatastoreResponse;
|
|
LSRequestPrepareObserverResponse;
|
|
};
|
|
|
|
/**
|
|
* An asynchronous protocol for issuing requests that are used in a synchronous
|
|
* fashion by LocalStorage via LSObject's RequestHelper mechanism. This differs
|
|
* from LSSimpleRequest which is implemented and used asynchronously.
|
|
*
|
|
* See `PBackgroundLSSharedTypes.ipdlh` for more on the request types, the
|
|
* response types above for their corresponding responses, and `RequestHelper`
|
|
* for more on the usage and lifecycle of this mechanism.
|
|
*/
|
|
protocol PBackgroundLSRequest
|
|
{
|
|
manager PBackground;
|
|
|
|
parent:
|
|
// The Cancel message is used to avoid a possible dead lock caused by a CPOW
|
|
// sending a synchronous message from the main thread in the chrome process
|
|
// to the main thread in the content process at the time we are blocking
|
|
// the main thread in the content process to handle a request.
|
|
// We use the PBackground thread on the parent side to handle requests, but
|
|
// sometimes we need to get information from principals and that's currently
|
|
// only possible on the main thread. So if the main thread in the chrome
|
|
// process is blocked by a CPOW operation, our request must wait for the CPOW
|
|
// operation to complete. However the CPOW operation can't complete either
|
|
// because we are blocking the main thread in the content process.
|
|
// The dead lock is prevented by canceling our nested event loop in the
|
|
// content process when we receive a synchronous IPC message from the parent.
|
|
//
|
|
// Note that cancellation isn't instantaneous. It's just an asynchronous flow
|
|
// that definitely doesn't involve the main thread in the parent process, so
|
|
// we're guaranteed to unblock the main-thread in the content process and
|
|
// allow the sync IPC to make progress. When Cancel() is received by the
|
|
// parent, it will Send__delete__. The child will either send Cancel or
|
|
// Finish, but not both.
|
|
async Cancel();
|
|
|
|
/**
|
|
* Sent by the child in response to Ready, requesting that __delete__ be sent
|
|
* with the result. The child will either send Finish or Cancel, but not
|
|
* both. No further message will be sent from the child after invoking one.
|
|
*/
|
|
async Finish();
|
|
|
|
child:
|
|
/**
|
|
* The deletion is sent with the result of the request directly in response to
|
|
* either Cancel or Finish.
|
|
*/
|
|
async __delete__(LSRequestResponse response);
|
|
|
|
/**
|
|
* Sent by the parent when it has completed whatever async stuff it needs to
|
|
* do and is ready to send the results. It then awaits the Finish() call to
|
|
* send the results. This may seem redundant, but it's not. If the
|
|
* __delete__ was sent directly, it's possible there could be a race where
|
|
* Cancel() would be received by the parent after it had already sent
|
|
* __delete__. (Which may no longer be fatal thanks to improvements to the
|
|
* IPC layer, but it would still lead to warnings, etc. And we don't
|
|
* expect PBackground to be highly contended nor the DOM File thread.)
|
|
*/
|
|
async Ready();
|
|
};
|
|
|
|
} // namespace dom
|
|
} // namespace mozilla
|