JJianliang Wang[Optimize] Support experimental iOS thread QoS
| Files | Last commit | Last update |
|---|---|---|
[Optimize] Introduce `EnableWeakFromThis` to replace `WeakPtrFactory` The currently used WeakPtrFactory and WeakPtrFlag have room for optimization in terms of performance and memory usage. SkipChecks:macro AutoSubmit:true | 1 year ago | |
[Optimize] Support experimental iOS thread QoS Add an experimental enable_platform_thread_scheduling_policy setting for Lynx platform threads on iOS. When enabled, Lynx threads are created and configured through Darwin QoS APIs instead of the legacy sched_priority and NSThread priority APIs. The legacy path remains the default when the setting is disabled. Expose a generic fml thread scheduling policy provider so the platform layer can control whether the QoS path is enabled without adding platform-specific logic to common thread code. SkipChecks:macro | 1 month ago | |
initial commit | 1 year ago | |
[Optimize] Introduce `EnableWeakFromThis` to replace `WeakPtrFactory` The currently used WeakPtrFactory and WeakPtrFlag have room for optimization in terms of performance and memory usage. SkipChecks:macro AutoSubmit:true | 1 year ago | |
initial commit | 1 year ago | |
[Optimize] Add missing EnsureInitializedForCurrentThread for concurrent threads Ensure that EnsureInitializedForCurrentThread is called for threads of concurrent pool. | 2 months ago | |
[Optimize] Improve CPUAffinity logic and move them to base Update CpuAffinity related codes to be consistent with upstream. | 1 year ago | |
[Optimize] Improve CPUAffinity logic and move them to base Update CpuAffinity related codes to be consistent with upstream. | 1 year ago | |
initial commit | 1 year ago | |
[BugFix] Various memory leaks caused by no-destruct MessageLoop Managing `MessageLoop` thread_local objects using `NoDestructor` can lead to numerous memory leaks. These include, but are not limited to, `MessageLoop`, `TaskRunner`, and `TaskQueue` objects. issue: m-7094905512 | 6 months ago | |
[BugFix] Fix leak of TaskQueueEntry created by TaskRunner TaskRunner is bound to MessageLoopImpl, and both register a TaskQueueEntry with MessageLoopTaskQueues by calling CreateTaskQueue. When TaskRunner is released, if there is a bound MessageLoopImpl, it will throw a task to the MessageLoopImpl and unregister the TaskQueueEntry with MessageLoopTaskQueues in the task callback. However, at this time, MessageLoopImpl is already in a terminated state, which prevents the unregistration from being completed, causing a TaskQueueEntry leak. issue: m-7094905512 | 6 months ago | |
[Reland][Optimize] Introduce vsync aligned queue to MessageLoopImpl This is the second part of optimizing vsync aligned message loop. In this MR, we introduce vsync aligned queue to MessageLoopImpl. And implement WakeUpByVSync interface in MessageLoopImpl so that it can align the execution of tasks with the vsync. issue: m-5672039058 | 1 year ago | |
[BugFix] Fix re-entrant deadlock in task queue disposal - Move task and queue entry destruction out of the MessageLoopTaskQueues lock scope by draining pending tasks and transferring TaskQueueEntry ownership before releasing resources. - Prevent destructors of delayed tasks, observers, and task sources from re-entering RegisterTask while queue_mutex_ is still held, which can deadlock during DisposeTasks and Dispose. - Add regression tests covering re-entrant RegisterTask calls triggered from task destruction and queue entry destruction. Verified with base_unittests_exec filters for DisposeTasksDoesNotHoldLockWhileDestroyingTasks and DisposeDoesNotHoldLockWhileDestroyingEntries. | 5 months ago | |
[Infra] Disable flaky ut case Disable flaky case in C++ ut. issue: #5312999715 | 8 months ago | |
[BugFix] Fix re-entrant deadlock in task queue disposal - Move task and queue entry destruction out of the MessageLoopTaskQueues lock scope by draining pending tasks and transferring TaskQueueEntry ownership before releasing resources. - Prevent destructors of delayed tasks, observers, and task sources from re-entering RegisterTask while queue_mutex_ is still held, which can deadlock during DisposeTasks and Dispose. - Add regression tests covering re-entrant RegisterTask calls triggered from task destruction and queue entry destruction. Verified with base_unittests_exec filters for DisposeTasksDoesNotHoldLockWhileDestroyingTasks and DisposeDoesNotHoldLockWhileDestroyingEntries. | 5 months ago | |
[Infra] Add log to locate ut timeout problem. Add some log to locate base unittests timeout problem. | 1 year ago | |
initial commit | 1 year ago | |
initial commit | 1 year ago | |
initial commit | 1 year ago | |
[BugFix] Fix leak of TaskQueueEntry created by TaskRunner TaskRunner is bound to MessageLoopImpl, and both register a TaskQueueEntry with MessageLoopTaskQueues by calling CreateTaskQueue. When TaskRunner is released, if there is a bound MessageLoopImpl, it will throw a task to the MessageLoopImpl and unregister the TaskQueueEntry with MessageLoopTaskQueues in the task callback. However, at this time, MessageLoopImpl is already in a terminated state, which prevents the unregistration from being completed, causing a TaskQueueEntry leak. issue: m-7094905512 | 6 months ago | |
[BugFix] Flush layout task queue in LayoutImmediatelyWithUpdatedViewport to prevent crash When calling LayoutImmediatelyWithUpdatedViewport, if the layout thread has not yet processed previous tasks, this invocation may effectively preempt the layout thread queue. If certain tasks have not been executed in time, such as the creation of a layout node, this could lead to a synchronous access to the node and cause a crash. To prevent task preemption and resolve this issue, we now execute pending tasks in the layout thread queue synchronously during Bind. | 1 year ago | |
[BugFix] Fix re-entrant deadlock in task queue disposal - Move task and queue entry destruction out of the MessageLoopTaskQueues lock scope by draining pending tasks and transferring TaskQueueEntry ownership before releasing resources. - Prevent destructors of delayed tasks, observers, and task sources from re-entering RegisterTask while queue_mutex_ is still held, which can deadlock during DisposeTasks and Dispose. - Add regression tests covering re-entrant RegisterTask calls triggered from task destruction and queue entry destruction. Verified with base_unittests_exec filters for DisposeTasksDoesNotHoldLockWhileDestroyingTasks and DisposeDoesNotHoldLockWhileDestroyingEntries. | 5 months ago | |
[BugFix] Fix re-entrant deadlock in task queue disposal - Move task and queue entry destruction out of the MessageLoopTaskQueues lock scope by draining pending tasks and transferring TaskQueueEntry ownership before releasing resources. - Prevent destructors of delayed tasks, observers, and task sources from re-entering RegisterTask while queue_mutex_ is still held, which can deadlock during DisposeTasks and Dispose. - Add regression tests covering re-entrant RegisterTask calls triggered from task destruction and queue entry destruction. Verified with base_unittests_exec filters for DisposeTasksDoesNotHoldLockWhileDestroyingTasks and DisposeDoesNotHoldLockWhileDestroyingEntries. | 5 months ago | |
[Optimize] Support experimental iOS thread QoS Add an experimental enable_platform_thread_scheduling_policy setting for Lynx platform threads on iOS. When enabled, Lynx threads are created and configured through Darwin QoS APIs instead of the legacy sched_priority and NSThread priority APIs. The legacy path remains the default when the setting is disabled. Expose a generic fml thread scheduling policy provider so the platform layer can control whether the QoS path is enabled without adding platform-specific logic to common thread code. SkipChecks:macro | 1 month ago | |
initial commit | 1 year ago | |
initial commit | 1 year ago | |
[Optimize] Support experimental iOS thread QoS Add an experimental enable_platform_thread_scheduling_policy setting for Lynx platform threads on iOS. When enabled, Lynx threads are created and configured through Darwin QoS APIs instead of the legacy sched_priority and NSThread priority APIs. The legacy path remains the default when the setting is disabled. Expose a generic fml thread scheduling policy provider so the platform layer can control whether the QoS path is enabled without adding platform-specific logic to common thread code. SkipChecks:macro | 1 month ago | |
initial commit | 1 year ago |