mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
75a7a52db4
Summary:
We're trying to build react-native on Windows (part of the Microsoft\react-native-windows project) with MSVC compiler with WITH_FBSYSTRACE set to true (to route the traces to ETW). This change is to fix a compilation error due to the non standard usage of ATOMIC_VAR_INIT macro called with no parameters. It's not absolutely clear to me the objective of this macro in the standard at all (to be used in c context ?), and which compiler does support this parameterless version (gcc?).
Also, I'm more inclined towards changing the statement to just "std::atomic_uint_least32_t m_systraceCookie{};". Please confirm.
## Changelog
[General] [Fixed] - Removing the non-standard usage of ATOMIC_VAR_INIT macro from code with systrace enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/26238
Test Plan: Build verification should suffice as there is no semantic change introduced by this change.
Differential Revision: D17259213
Pulled By: cpojer
fbshipit-source-id: 9fe44f9220f18399a58f94f0f01d5fa93e6458e0
115 lines
3.6 KiB
C++
115 lines
3.6 KiB
C++
// Copyright (c) Facebook, Inc. and its affiliates.
|
|
|
|
// This source code is licensed under the MIT license found in the
|
|
// LICENSE file in the root directory of this source tree.
|
|
|
|
#pragma once
|
|
|
|
#include <atomic>
|
|
#include <functional>
|
|
#include <map>
|
|
#include <vector>
|
|
|
|
#include <cxxreact/JSExecutor.h>
|
|
|
|
namespace folly {
|
|
struct dynamic;
|
|
}
|
|
|
|
namespace facebook {
|
|
namespace react {
|
|
|
|
struct InstanceCallback;
|
|
class JsToNativeBridge;
|
|
class MessageQueueThread;
|
|
class ModuleRegistry;
|
|
class RAMBundleRegistry;
|
|
|
|
// This class manages calls from native code to JS. It also manages
|
|
// executors and their threads. All functions here can be called from
|
|
// any thread.
|
|
//
|
|
// Except for loadApplicationScriptSync(), all void methods will queue
|
|
// work to run on the jsQueue passed to the ctor, and return
|
|
// immediately.
|
|
class NativeToJsBridge {
|
|
public:
|
|
friend class JsToNativeBridge;
|
|
|
|
/**
|
|
* This must be called on the main JS thread.
|
|
*/
|
|
NativeToJsBridge(
|
|
JSExecutorFactory* jsExecutorFactory,
|
|
std::shared_ptr<ModuleRegistry> registry,
|
|
std::shared_ptr<MessageQueueThread> jsQueue,
|
|
std::shared_ptr<InstanceCallback> callback);
|
|
virtual ~NativeToJsBridge();
|
|
|
|
/**
|
|
* Executes a function with the module ID and method ID and any additional
|
|
* arguments in JS.
|
|
*/
|
|
void callFunction(std::string&& module, std::string&& method, folly::dynamic&& args);
|
|
|
|
/**
|
|
* Invokes a callback with the cbID, and optional additional arguments in JS.
|
|
*/
|
|
void invokeCallback(double callbackId, folly::dynamic&& args);
|
|
|
|
/**
|
|
* Starts the JS application. If bundleRegistry is non-null, then it is
|
|
* used to fetch JavaScript modules as individual scripts.
|
|
* Otherwise, the script is assumed to include all the modules.
|
|
*/
|
|
void loadApplication(
|
|
std::unique_ptr<RAMBundleRegistry> bundleRegistry,
|
|
std::unique_ptr<const JSBigString> startupCode,
|
|
std::string sourceURL);
|
|
void loadApplicationSync(
|
|
std::unique_ptr<RAMBundleRegistry> bundleRegistry,
|
|
std::unique_ptr<const JSBigString> startupCode,
|
|
std::string sourceURL);
|
|
|
|
void registerBundle(uint32_t bundleId, const std::string& bundlePath);
|
|
void setGlobalVariable(std::string propName, std::unique_ptr<const JSBigString> jsonValue);
|
|
void* getJavaScriptContext();
|
|
bool isInspectable();
|
|
bool isBatchActive();
|
|
|
|
void handleMemoryPressure(int pressureLevel);
|
|
|
|
/**
|
|
* Synchronously tears down the bridge and the main executor.
|
|
*/
|
|
void destroy();
|
|
|
|
void runOnExecutorQueue(std::function<void(JSExecutor*)> task);
|
|
|
|
private:
|
|
// This is used to avoid a race condition where a proxyCallback gets queued
|
|
// after ~NativeToJsBridge(), on the same thread. In that case, the callback
|
|
// will try to run the task on m_callback which will have been destroyed
|
|
// within ~NativeToJsBridge(), thus causing a SIGSEGV.
|
|
std::shared_ptr<bool> m_destroyed;
|
|
std::shared_ptr<JsToNativeBridge> m_delegate;
|
|
std::unique_ptr<JSExecutor> m_executor;
|
|
std::shared_ptr<MessageQueueThread> m_executorMessageQueueThread;
|
|
|
|
// Memoize this on the JS thread, so that it can be inspected from
|
|
// any thread later. This assumes inspectability doesn't change for
|
|
// a JSExecutor instance, which is true for all existing implementations.
|
|
bool m_inspectable;
|
|
|
|
// Keep track of whether the JS bundle containing the application logic causes
|
|
// exception when evaluated initially. If so, more calls to JS will very
|
|
// likely fail as well, so this flag can help prevent them.
|
|
bool m_applicationScriptHasFailure = false;
|
|
|
|
#ifdef WITH_FBSYSTRACE
|
|
std::atomic_uint_least32_t m_systraceCookie = ATOMIC_VAR_INIT(0);
|
|
#endif
|
|
};
|
|
|
|
} }
|