Asynchronous resource control method, system, device and storage medium

Abstract

This application relates to an asynchronous resource control method, system, device, and storage medium. The method includes: obtaining a resource control context for a rendering task, the resource control context including an identifier of the rendering task, a rendering task state, a controller set, and a data storage area; if, based on a scheduling notification of the rendering task and the controller set, it is determined that the rendering task is interrupted, then generating an interrupt instruction including the identifier; in response to the interrupt instruction, deleting the resource control context object corresponding to the resource control context and releasing memory. The solution provided by this application can achieve deterministic control of asynchronous resources and significantly reduce the risk of asynchronous resource leakage.

Description

Technical Field

[0001] This application relates to the fields of computer software engineering and distributed system resource management technology, and in particular to an asynchronous resource control method, system, device and storage medium. Background Technology

[0002] Modern front-end frameworks (such as React 18 and Vue 3) introduce advanced scheduling models with concurrent rendering and interruptible update mechanisms, which significantly improve the interactivity and responsiveness of front-end applications.

[0003] However, this advanced scheduling model has a technical defect at the architectural level that causes cross-layer lifecycle information discontinuity in cross-layer interaction scenarios of front-end frameworks. That is, in cross-layer interaction scenarios of front-end frameworks, the state information of different levels such as component lifecycle, rendering scheduling, and cross-layer protocol interaction cannot be completely and continuously linked and traced, resulting in information breakpoints in the entire lifecycle events and making it impossible to restore the complete execution flow. Specifically, modern front-end frameworks that introduce concurrent rendering and interruptible update mechanisms, in a concurrent model, when a low-priority rendering task Task_A (e.g., preloading complex charts in the background) is interrupted by a high-priority task Task_B (e.g., user input), at the framework layer, the scheduler immediately stops the DOM (Document Object Model) computation and updates of Task_A, releasing related memory. At the application layer, asynchronous side effects triggered by Task_A (e.g., fetch requests, setTimeout, Web Worker communication) do not stop automatically; these asynchronous side effect requests continue to consume network bandwidth, client memory, and CPU computing resources. At the data layer, when the delayed asynchronous side effect requests finally return data, due to the lack of effective context association, the returned data is incorrectly written to the global state management library (e.g., Redux, Zustand), leading to state pollution and UI inconsistency (e.g., data from the old chart overwrites data from the new chart).

[0004] In related technologies, requests for manually cleaning up asynchronous side effects rely on the component's Unmount event, based on the component lifecycle. However, in concurrent rendering, an interruption of the rendering task does not equate to the component being unmounted (the component may still be mounted on the DOM, but it has been discarded in this update). The inability to detect interruptions outside of Unmount leads to ineffective cleanup. Alternatively, heuristic caching strategies (e.g., React Query, SWR) are used to clean up asynchronous side effects based on "component unmounting" or "stale-while-revalidate," but heuristic caching strategies are probabilistic and lagging, unable to achieve deterministic recycling synchronized with rendering scheduling, and unable to handle edge cases where "rendering intent fails but the component is not unmounted."

[0005] Therefore, the interruptible rendering architecture, which introduces concurrent rendering and an interruptible update mechanism, cannot cancel asynchronous requests that have already been issued after the rendering task is interrupted, and cannot achieve deterministic control of resources, resulting in resource leaks and state pollution. Summary of the Invention

[0006] To address or partially address the problems existing in related technologies, this application provides an asynchronous resource control method, system, device, and storage medium, which can achieve deterministic control of asynchronous resources and significantly reduce the risk of asynchronous resource leakage.

[0007] A first aspect of this application provides an asynchronous resource control method, the method comprising: Obtain the resource control context of the rendering task, wherein the resource control context includes the identifier of the rendering task, the rendering task status, the controller set, and the data storage area; If it is determined, based on the scheduling notification of the rendering task and the controller set, that the rendering task is interrupted, then an interruption instruction including the identifier is generated. In response to the interrupt instruction, the resource control context object corresponding to the resource control context is deleted, and memory is released.

[0008] In one implementation, if it is determined, based on the rendering task's scheduling notification and the controller set, that the rendering task is interrupted, then generating an interruption instruction including the identifier includes: If it is determined from the scheduling notification of the rendering task that the scheduling of the rendering task has ended, then obtain the signal of the controller in the controller set; If, based on the signal, it is determined that the asynchronous operation associated with the controller has not been completed, then it is determined that the rendering task has been interrupted. If it is determined that the rendering task has been interrupted, an interruption instruction including the identifier is generated.

[0009] In one implementation, before deleting the resource control context object corresponding to the resource control context and releasing memory in response to the interrupt instruction, the process includes: In response to the interrupt instruction, the resource control context including the identifier is obtained based on the identifier included in the interrupt instruction; Update the rendering task status of the resource control context, including the identifier, to be interrupted; Based on the controller set of the resource control context, obtain the signals of the controllers in the controller set; Based on the signals from the controllers in the controller set, obtain the calling function of the asynchronous application programming interface that includes the signals; The asynchronous side effects corresponding to the called function are aborted based on the function call of the asynchronous application programming interface that includes the signal.

[0010] In one embodiment, the method further includes: Obtain the identifier included in the returned data; Based on the identifier, obtain the resource control context including the identifier; If the rendering task status of the resource control context including the identifier is interrupted, the returned data and the metadata of the returned data are marked as invalid data and stored in the data storage area.

[0011] In one implementation, the step of deleting the resource control context object corresponding to the resource control context and releasing memory in response to the interrupt instruction includes: In response to the interrupt instruction, when the main thread is idle, the resource control context including the identifier in the resource control context stack is obtained; Delete the resource control context object corresponding to the resource control context, the reference to the resource control context object, and / or the mapping entry between the identifier and the resource control context, and release memory; and / or, delete the invalid data in the data storage area, and the storage reference storing the invalid data, and release memory.

[0012] In one implementation, obtaining the resource control context of the rendering task includes: Upon receiving the task start notification for the rendering task, an identifier for the rendering task is generated, and a resource control context object for the rendering task is created. Obtain the asynchronous operation for rendering the rendering task, create a controller for the asynchronous operation, and write the signal of the controller into the calling function of the asynchronous application programming interface, wherein the asynchronous operation is a specific execution instance formed after the asynchronous application programming interface is called; Write the controller to the controller set, write the identifier and the rendering task status to the resource control context object, establish an implicit association between the identifier and the asynchronous operation in the data storage area, and obtain the resource control context of the rendering task.

[0013] A second aspect of this application provides an asynchronous resource control system, the system comprising: The context acquisition unit is used to acquire the resource control context of the rendering task, wherein the resource control context includes the identifier of the rendering task, the rendering task status, the controller set, and the data storage area; The instruction generation unit is configured to generate an interruption instruction including the identifier if it is determined, based on the scheduling notification of the rendering task and the set of controllers in the resource control context obtained by the context acquisition unit, that the rendering task is interrupted. The resource reclamation unit is used to delete the resource control context object corresponding to the resource control context and release memory in response to the interrupt instruction generated by the instruction generation unit.

[0014] In one embodiment, the system further includes: A termination unit is configured to, in response to the interrupt instruction, obtain the resource control context including the identifier according to the identifier included in the interrupt instruction; update the rendering task status of the resource control context including the identifier to be interrupted; obtain the signals of the controllers in the controller set according to the controller set of the resource control context; obtain the calling function of the asynchronous application programming interface including the signal according to the signal of the controller in the controller set; and terminate the asynchronous side effect corresponding to the calling function according to the calling function of the asynchronous application programming interface including the signal. A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0015] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0016] The fifth aspect of this application provides a computer program product comprising computer instructions that, when executed by a processor, implement the method described above.

[0017] The technical solution provided in this application may include the following beneficial results: The technical solution of this application, based on the resource control context of the rendering task of the interruptible rendering engine, listens for or infers the rendering task interruption event (distinct from the component unloading event) when the rendering task of the interruptible rendering engine is interrupted, and drives the application layer resource reclamation based on the rendering task interruption event, thereby realizing cross-layer event-driven asynchronous resource control between the "interruptible rendering engine scheduling layer" and the "application business logic layer". This achieves an asynchronous resource control that is independent of the interruptible rendering engine and not bound to the implementation details of the interruptible rendering engine, enabling deterministic control of asynchronous resources and significantly reducing the risk of asynchronous resource leakage.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0020] Figure 1 This is a flowchart illustrating the asynchronous resource control method in an embodiment of this application; Figure 2 This is another schematic flowchart illustrating the asynchronous resource control method in the embodiments of this application; Figure 3 This is a schematic diagram of the asynchronous resource control system shown in the embodiments of this application; Figure 4 This is another structural schematic diagram of the asynchronous resource control system shown in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0021] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0022] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0024] This application provides an asynchronous resource control method that enables deterministic control of asynchronous resources and significantly reduces the risk of asynchronous resource leakage.

[0025] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0026] Figure 1 This is a flowchart illustrating the asynchronous resource control method shown in the embodiments of this application.

[0027] See Figure 1 An asynchronous resource control method, comprising: Step 101: Obtain the resource control context of the rendering task. The resource control context includes the identifier of the rendering task, the rendering task status, the controller set, and the data storage area.

[0028] In one embodiment, when the interruptible rendering engine begins rendering a rendering task, a task start notification (onTaskStart) is issued first. Upon receiving the task start notification (onTaskStart), the resource control context (RCC) of the rendering task can be obtained. The resource control context may include the rendering task identifier (TaskID), rendering task status (status), controller set (controllerSet), and data store (dataStore).

[0029] Step 102: If it is determined that the rendering task is interrupted based on the scheduling notification of the rendering task and the set of controllers of the resource control context, then an interruption instruction including an identifier is generated.

[0030] In one embodiment, during the rendering process of an interruptible rendering engine for a rendering task, if the interruptible rendering engine receives a higher-priority rendering task, it issues a rendering task scheduling notification "Rendering task scheduling has ended." The rendering task scheduling notification may include the identifier of the rendering task. Based on the rendering task scheduling notification "Rendering task scheduling has ended," a resource control context including the identifier of the rendering task is obtained. Based on the controller signal (AbortSignal) in the controller set of the resource control context, it is determined whether the asynchronous operation associated with the controller has been completed. If the asynchronous operation associated with the controller has not been completed, it is determined that the rendering task is interrupted, and an interrupt instruction including the identifier of the rendering task is generated.

[0031] Step 103: In response to the interrupt instruction, delete the resource control context object corresponding to the resource control context and release the memory.

[0032] In one embodiment, in response to an interrupt command including an identifier of a rendering task, a resource control context including the identifier of the rendering task in the interrupt command can be obtained, and the resource control context object corresponding to the resource control context can be deleted to release the memory occupied by the resource control context, so as to reclaim the memory resources occupied by the resource control context in a timely manner.

[0033] The asynchronous resource control method of this application embodiment listens for or infers the rendering task interruption event (distinct from component unloading event) of the rendering task of the interruptible rendering engine being interrupted, based on the resource control context of the rendering task of the interruptible rendering engine, and drives application layer resource reclamation based on the rendering task interruption event. This realizes cross-layer event-driven asynchronous resource control between the "interruptible rendering engine scheduling layer" and the "application business logic layer", achieving an asynchronous resource control that is independent of the interruptible rendering engine and not bound to the implementation details of the interruptible rendering engine. It can achieve deterministic control of asynchronous resources and significantly reduce the risk of asynchronous resource leakage.

[0034] Figure 2 This is another flowchart illustrating the asynchronous resource control method in the embodiments of this application. Figure 2 Compared to Figure 1 The scheme of this application is described in more detail.

[0035] See Figure 2 An asynchronous resource control method, comprising: Step 201: Create an identifier and resource control context object corresponding to the rendering task.

[0036] In one embodiment, upon receiving a task start notification for a rendering task, an identifier for the rendering task is generated, and a resource control context object for the rendering task is created; the resource control context object may include an identifier field, a task status field, a controller collection field, and a data storage field.

[0037] In one embodiment, when the interruptible rendering engine starts rendering a rendering task, it can receive a task start notification (onTaskStart) from the interruptible rendering engine scheduler through the adapter interface provided by the interruptible rendering engine. When the task start notification (onTaskStart) is received, a globally unique identifier (TaskID) is immediately generated for the rendering task currently being rendered by the interruptible rendering engine, and a resource control context (RCC) object is instantiated for the rendering task. The RCC object of the rendering task is written to the global resource control context stack, and the RCC object of the rendering task is marked as the currently active resource control context object.

[0038] In one embodiment, the RCC object may include an identifier field, a task status field, a controller set field, and a data storage field. The identifier field contains the TaskID identifier of the rendering task, used to associate the rendering task. The task status field contains the rendering task's status, which can be either ACTIVE or INTERRUPTED, indicating whether the rendering task is active or interrupted. The controller set field contains the controller set, which stores references to all asynchronous side effects derived from this rendering task, such as AbortController instances, supporting batch abort operations. The data storage field implements a data store (dataStore) using WeakMap, which can be a logically isolated area (Orphan DataStore) used to maintain a weak reference mapping between rendering tasks and asynchronous operation results, avoiding memory leaks and supporting the isolation and reclamation of invalid data. For example, the data structure of the RCC object could be RCC={taskId: string, status: 'ACTIVE'| 'INTERRUPTED', controllerSet: Set} <controller>, dataStore: WeakMap}.

[0039] In one embodiment, during client-side rendering runtime with task scheduling priority preemption capabilities, the interruptible rendering engine's scheduling model allows high-priority tasks to preempt the execution resources of low-priority tasks. Interruptible rendering engines are not limited to specific framework implementations (React 18 Concurrent Mode and Vue 3 Suspense are concrete examples); they are a general term for a type of rendering scheduling paradigm characterized by interruptibility and resumability. A rendering task is an atomic view update unit managed by the interruptible rendering engine scheduler, possessing a unique identifier (TaskID) and lifecycle state.

[0040] Step 202: Obtain the resource control context of the rendering task based on the asynchronous side effects of the rendering task.

[0041] In one embodiment, the asynchronous operation of the rendering task can be obtained, a controller can be created for the asynchronous operation, and the signal of the controller can be written into the calling function of the asynchronous application programming interface. The asynchronous operation is a specific execution instance formed after the asynchronous application programming interface is called. The controller is written into the controller collection, the identifier of the rendering task and the rendering task status are written into the resource control context object, and an implicit association between the identifier and the asynchronous operation is established in the data storage area to obtain the resource control context of the rendering task.

[0042] In one embodiment, the asynchronous side effects of interruptible rendering engine rendering tasks can broadly refer to all asynchronous behaviors derived from rendering tasks that have side effects, including network requests, timers, event listeners, and Web Worker communication. An asynchronous API (Application Programming Interface) is the underlying capability for generating asynchronous operations. An asynchronous operation is a specific execution instance formed after an asynchronous API is called, possessing dynamic lifecycle states such as pending and settled. Asynchronous requests refer to asynchronous operations of the network communication class.

[0043] In one embodiment, the resource control context is a logical container strongly bound to a single rendering task, used to maintain controller references and states for all asynchronous side effects derived from that rendering task. During the rendering process of the interruptible rendering engine, when business code calls asynchronous APIs such as `fetch` (to retrieve an interface), `axios`, `setTimeout` (timeout timer), and `addEventListener` (to add an event listener), a proxy interceptor can be used to create a controller instance corresponding to the asynchronous operation type (e.g., creating a new `AbortController` instance via `new AbortController()` (a constructor for creating an `AbortController` instance) or generating a unique `cancelToken`). This controller instance is then written to the controller collection of the currently active resource control context object of the current rendering task. The controller instance's signal (e.g., `AbortSignal`) is written to the call parameters of the asynchronous API (e.g., `fetch(url, { signal})`). An implicit association between the rendering task's `TaskID` and the asynchronous operation is established in the data storage area, and a weak mapping (`WeakMap`) is used to maintain the mapping between `TaskID` and `Promise` (the final result carrier of the asynchronous operation). By intercepting asynchronous API calls and writing the controller instance's signals into the asynchronous API call parameters, a binding relationship is established between the asynchronous operation and the currently active RCC. This allows the controller instance to subsequently perform batch aborts and resource reclamation on specific asynchronous side effects, achieving fine-grained management of the asynchronous side effect lifecycle and data state. In one embodiment, for network requests such as fetch and axios, the controller instance corresponds to the browser's native AbortController object or its derived AbortSignal; for timers such as setTimeout and setInterval, it corresponds to the generated unique cancelToken or timer ID; for event listeners such as addEventListener, it corresponds to the handle applied to remove the listener or the injected AbortSignal; for other asynchronous side effects such as Web Worker communication and animation frames, it corresponds to the termination handle provided by the respective framework or platform (e.g., the Worker's terminate signal, the frame ID of requestAnimationFrame). These controller instances are created when the asynchronous operation is initiated and registered in the controllerSet collection of the currently active RCC. When the rendering task is interrupted, the abort() or cancel() method of each controller instance is synchronously called by traversing the controllerSet collection, thereby achieving batch deterministic termination of different types of asynchronous side effects.

[0044] Step 203: If it is determined that the rendering task has been interrupted, an interruption instruction including the identifier of the rendering task is generated.

[0045] In one embodiment, if it is determined from the scheduling notification of the rendering task that the scheduling of the rendering task has ended, then the signal of the controller in the controller set is obtained; if it is determined from the signal of the controller that the asynchronous operation associated with the controller has not been completed, then it is determined that the rendering task has been interrupted; if it is determined that the rendering task has been interrupted, then an interrupt instruction including an identifier is generated.

[0046] In one embodiment, the scheduling status of the interruptible rendering engine can be continuously monitored. The interruption event of a rendering task being interrupted can be identified through the callback specificity of the task settlement callback (onTaskSettle) of the interruptible rendering engine adapter. That is, when the adapter notifies that "the rendering task has finished scheduling," if there are still unfinished asynchronous operations (the lifecycle state of the Promise is Pending) in the controller set of the currently active resource control context, it is inferred that the rendering task corresponding to the TaskID in the currently active resource control context has been interrupted, and an interruption command including the TaskID is generated. The criterion for determining whether a rendering task has been interrupted is solely the inconsistency between "scheduling finished" and "asynchronous operation not completed," rather than any internal flag of any specific front-end framework.

[0047] In one embodiment, a rendering interruption event is an internal signal issued by the interruptible rendering engine scheduler, indicating that a rendering task has been permanently terminated due to preemption by a higher-priority task. Rendering interruption events are internal state changes within the scheduling layer, unlike component-level unmount events (where the component may still be mounted on the DOM tree, but the current rendering task update is discarded).

[0048] In one embodiment, when the front-end framework is React, a state flag inference method can be used to detect whether the rendering task has been interrupted. The `startTransition Hook` is wrapped, and its returned `isPending` state is obtained (a boolean state returned by `useTransition Hook`, indicating whether a transition update is currently in progress but not yet completed). When `isPending` changes from `true` to `false` (indicating the end of scheduling), and the controller signals in the current active resource control context's controller set still indicate unfinished asynchronous operations, the task settlement callback (`taskId, 'interrupted'`) is called through the front-end framework adapter. This reverse inference infers that the rendering task corresponding to the `TaskID` in the task settlement callback has been interrupted, generating an interruption command including the `TaskID`.

[0049] In one embodiment, when the front-end framework is Vue or Solid, a lifecycle lookup method can be used to detect whether the rendering task has been interrupted. Interception logic is injected into the `onError` hook (error catching hook) of the Suspense component or the asynchronous component loader. When the loading process is preempted by a new, higher-priority rendering task, the front-end framework triggers a specific lifecycle callback. This callback is captured by the front-end framework adapter and `onTaskSettle(taskId, 'interrupted')` is called. This allows for reverse inference that the rendering task corresponding to the `TaskID` in the lifecycle callback has been interrupted, generating an interruption command including the `TaskID`.

[0050] In one embodiment, a scheduler hook method can be used to detect whether a rendering task has been interrupted. A task completion callback is registered using an internal API provided by the interruptible rendering engine (e.g., the Scheduler API). If the task completion callback is invoked without a corresponding completion flag, it is determined that the rendering task corresponding to the TaskID in the task completion callback has been interrupted, and an interruption command including the TaskID is generated.

[0051] Step 204: In response to an interrupt instruction including an identifier, batch deterministically abort the asynchronous side effects of the rendering task.

[0052] In one embodiment, in response to an interrupt instruction including an identifier, a resource control context including the identifier is obtained based on the identifier included in the interrupt instruction; the rendering task state of the resource control context including the identifier is updated to be interrupted; based on the controller set of the resource control context, the signals of the controllers in the controller set are obtained; based on the signals of the controllers in the controller set, the calling function of the asynchronous application programming interface including the signal is obtained; based on the calling function of the asynchronous application programming interface including the signal, the asynchronous side effects corresponding to the calling function are aborted.

[0053] In one embodiment, in response to an interrupt command including an identifier, the resource control context including that identifier can be located; the rendering task state of the resource control context (used to identify the current running stage of the resource control context session and component task) can be set to INTERRUPTED; the controllers of the controller set in the resource control context can be traversed, and the abort() or cancel() methods of all controller instances can be called synchronously (methods used to terminate or cancel ongoing asynchronous operations (such as network requests, scheduled tasks, animations, etc.)); based on the signals of the controller instances, the asynchronous API call parameters written to the controller instances can be obtained; based on the asynchronous API call parameters written to the controller instances, the asynchronous side effects can be immediately and deterministically aborted through the browser kernel or adapter. For example, clearing timers or removing event listeners.

[0054] In one embodiment, the rendering task state of the resource control context includes two states: ACTIVE and INTERRUPTED. The resource control context is considered to have completed normally when the adapter notifies that the rendering task scheduling has ended and all asynchronous operations within the controllerSet have been settled (task completion and final state). In the ACTIVE state, business code is allowed to initiate asynchronous side effects and register its controllers with the currently active resource control context. Asynchronous data is also allowed to be written to the application state tree normally after return. When the task completes normally, the resource control context will naturally exit the global resource control context stack, and its associated asynchronous resources will be released as they complete normally. Data writing will no longer be intercepted, and the resource control context object will wait for the idle period recycling task for final cleanup and destruction. When the rendering task state of the resource control context is INTERRUPTED, the resource control context controller set can be immediately traversed to perform batch deterministic aborts. All subsequently returned delayed data will be identified by the response interceptor and transferred to the data storage area for logical isolation, preventing delayed data from entering the application layer state tree, until the idle period recycling task physically deletes the data reference and destroys the resource control context object.

[0055] Step 205: Through state isolation and logical reclamation, the returned invalid data is stored in the data storage area.

[0056] In one embodiment, the identifier included in the returned data can be obtained; based on the identifier, the resource control context including the identifier can be obtained; if the rendering task status of the resource control context including the identifier is interrupted, the returned data and the metadata of the returned data are marked as invalid data and stored in the data storage area.

[0057] In one embodiment, if the asynchronous side effects of a rendering task are not terminated in a timely manner, the asynchronous data (lagging data) returned after the asynchronous side effects of the rendering task are deterministically terminated in batches in response to an interrupt instruction including an identifier can be processed by wrapping `Promise.prototype.then` (specifying the callback function to be executed when the Promise state becomes fulfilled or rejected) or by reactive interception (Vue's `watch` (a reactive listening mechanism) or React's `setState` hijacking). The process checks the RCC state corresponding to the TaskID associated with the asynchronous data. If the RCC state is INTERRUPTED, the returned asynchronous data is not written to the application layer state tree (without calling `setState` or `ref.value` assignment), and the asynchronous data and its metadata (TaskID, timestamp) are stored in a logical isolation area (Orphan Data Store). This logical isolation area is implemented using a WeakMap, is invisible to business logic, and is only used for subsequent garbage collection.

[0058] Step 206: Asynchronous resource reclamation during idle periods of coordinated scheduling.

[0059] In one embodiment, in response to an interrupt instruction including an identifier, when the main thread is idle, the resource control context including the identifier is obtained from the resource control context stack; the resource control context object corresponding to the resource control context, the resource control context object reference, and / or the mapping entry between the identifier and the resource control context are deleted to release memory; and / or invalid data in the data storage area and the storage reference storing the invalid data are deleted to release memory.

[0060] In one embodiment, a low-priority cleanup task can be registered using the browser's requestIdleCallback API or the interruptible rendering engine's postCommit hook. When the main thread is idle, the task scans the logical isolation zone, physically deletes all data references marked as invalid, deletes the RCC objects of the interrupted rendering task to release memory, and cleans up the corresponding records in the global resource control context stack.

[0061] The asynchronous resource control method in this application can serve as an interruption-aware coordination layer located between the interruptible rendering engine and the application business logic layer. It decouples itself from the interruptible rendering engine through a framework adapter interface, enabling it to adapt to the implementation differences of different interruptible rendering engines. It is responsible for converting scheduling events from the framework layer into resource control instructions from the application layer, achieving deterministic coordination control between asynchronous resources in the application layer and the rendering scheduling of the interruptible rendering engine. It establishes a cross-layer signal link, transforming the opaque rendering task interruption events of the interruptible rendering engine into standard control signals that can be consumed by the application business logic layer through the adapter interface, thus building a coordination bridge between the interruptible rendering engine and the application business logic layer. The interruption-aware collaborative control layer listens for or infers rendering task interruption events (distinct from component unloading events) based on the resource control context of the rendering tasks of the interruptible rendering engine. It then drives the reclamation of asynchronous resources in the application layer based on these interruption events. This achieves cross-layer event-driven asynchronous resource control between the "interruptible rendering engine scheduling layer" and the "application business logic layer," establishing a deterministic asynchronous resource control link from the scheduling layer to the application business logic layer. This provides a deterministic asynchronous resource control independent of the interruptible rendering engine and not bound to its implementation details. It does not rely on the internal implementation of any specific front-end framework, solving the problems of resource leakage and state pollution caused by rendering task interruptions. It enables deterministic control of asynchronous resources and significantly reduces the risk of asynchronous resource leakage.

[0062] Furthermore, in the asynchronous resource control method of this application embodiment, if it is determined from the scheduling notification of the rendering task that the scheduling of the rendering task has ended, the signal of the controller in the controller set is obtained; if it is determined from the signal of the controller that the asynchronous operation associated with the controller has not been completed, the rendering task is determined to be interrupted. An interruption discrimination algorithm independent of the interruptible rendering engine is adopted. Through a specific interruption inference logic based on inconsistency, the inconsistency between "the rendering task has ended scheduling" and "the asynchronous operation in the resource control context has not been completed" is monitored, and the interruption of the rendering task is inferred in reverse. The judgment basis for inferring that the rendering task has been interrupted is the abstract "scheduling state-resource state" inconsistency relationship, rather than the API flag of the interruptible rendering engine. It does not rely on the internal implementation of a specific front-end framework, thus implementing an interruption discrimination algorithm independent of the interruptible rendering engine, which can improve the accuracy and efficiency of judging whether the rendering task has been interrupted.

[0063] Furthermore, the asynchronous resource control method in this application creates a dedicated resource control context for each independent rendering task instance. Using the task-granular resource control context as a container, it realizes a strong binding relationship between asynchronous resources (network, timers, etc.) and rendering tasks, performs batch binding, batch termination, and batch recycling of asynchronous resources, solves the problem of resource fragmentation management, and enables batch management and atomic operations of asynchronous resources.

[0064] Furthermore, the asynchronous resource control method in this application embodiment checks the rendering task status in the resource control context to determine whether the asynchronous data returned after the rendering task is interrupted is invalid data; it physically stores the invalid data (lagging data) in a logical isolation area to achieve isolated storage of invalid data and prevent invalid asynchronous data from polluting the application layer state tree; it establishes a binding relationship between rendering intent and data validity, automatically isolates and cleans up invalid data, fundamentally prevents state tree pollution, and ensures strong consistency of data state.

[0065] Furthermore, the asynchronous resource control method in this application embodiment, in response to an interruption command that interrupts the rendering task, stops the asynchronous side effects of the rendering task, reduces bandwidth consumption and memory usage by immediately canceling invalid network requests and computational tasks; when the main thread is idle, it deletes invalid data in the resource control context and data storage area of ​​the interrupted rendering task, and binds the resource cleanup task to the idle callback of the browser or interruptible rendering engine through the idle period callback scheduling strategy, so as to achieve conflict-free coordination between high-priority interaction and background asynchronous resource reclamation, and utilizes the idle period to perform low-priority cleanup, optimizes the utilization rate of asynchronous resources, avoids main thread blocking, and improves overall running efficiency.

[0066] The asynchronous resource control method of this application is illustrated below with specific embodiments in specific application scenarios.

[0067] Example 1: In a React 18 + TypeScript application scenario, when a user clicks "Switch Dimension" on the "BI Data Report" page (high-priority rendering task_B), the background is preloading "Detailed Data for 2023" (low-priority rendering task_A).

[0068] In Embodiment 1, the asynchronous resource control method of this application is applied to the interruption-aware collaborative control layer, and the timing process includes: Step A01, low-priority rendering task Task_A starts: the user triggers startTransition(() =>{setDimension('2023')}). The interrupt-aware co-control layer hooks useInterruptibleTask to capture this call, creates RCC_A (TaskID: t-1001), and writes it to the global resource control context stack.

[0069] Step A02, side effect registration: report component rendering, call useControlledFetch(' / api / data?year=2023').

[0070] The collaboration layer intercepts fetch and creates AbortController_1.

[0071] Add AbortController_1 to RCC_A.controllerSet.

[0072] Initiate a request: fetch(' / api / data?year=2023', { signal: AbortController_1.signal}).

[0073] Step A03, Interruption occurs: The user immediately clicks "Switch to 2024". The React scheduler interrupts the low-priority rendering task Task_A and begins rendering the high-priority rendering task Task_B.

[0074] Step A04, Interruption Detection: The useInterruptibleTask detected that isPending changed from true to false.

[0075] Upon checking RCC_A.controllerSet, it was found that the signal for AbortController_1 was not triggered (the request was still in flight).

[0076] Inference logic: isPending=false + There is an unfinished controller = Low-priority rendering task Task_A was interrupted.

[0077] Generate an interrupt instruction and set RCC_A.status = 'INTERRUPTED'.

[0078] Step A05, Resource Abort: The interruption-aware collaborative control layer iterates through RCC_A.controllerSet and executes AbortController_1.abort(). The browser immediately terminates the HTTP connection (TCP RST).

[0079] Step A06, Data Isolation: Assume the request was sent before abort, and the server response is returned 200ms later.

[0080] The interrupt-aware collaborative control layer's response interceptor (wrapped then) captures the Response.

[0081] Checking the RCC_A status revealed it to be INTERRUPTED.

[0082] setData(response) will not be executed.

[0083] Store the Response in the Orphan Data Store (WeakMap) with the key t-1001.

[0084] Step A07, Idle Recycling: The browser enters requestIdleCallback, the cleanup task checks that RCC_A is interrupted and has no references, destroys RCC_A and deletes the data from the Orphan Data Store.

[0085] Technical effect comparison: In related technologies, a request to continue flying is made, and data is returned after 200ms, which incorrectly updates the "2024" report UI, causing data flickering or errors. In the embodiment of this application, the request is canceled, and even if there is a delayed response, it is isolated. The UI maintains the "2024" loading state or correctly displays cached data, avoiding UI inconsistencies caused by data backfilling.

[0086] Example 2: In online collaborative document applications, users frequently switch pages or move the collaboration cursor while editing documents, causing the background "auto-save" or "image upload" tasks to be frequently interrupted. If left unaddressed, this can result in "old version overwriting new version" or incorrect insertion of uploaded images.

[0087] In Embodiment 2, when editing a document, the asynchronous resource control method of this application embodiment is used. The asynchronous resource control method of this application embodiment is applied to the interruption-aware collaborative control layer, and its steps include: User input triggers a high-priority rendering task (Task_High).

[0088] The background automatically saves the low-priority rendering task (Task_Low) upon startup. The interruption-aware collaborative control layer creates the RCC_Save of the low-priority rendering task (Task_Low) and registers the upload request.

[0089] When a user suddenly switches paragraphs, React interrupts Task_Low.

[0090] The interruption-aware collaborative control layer detects the interruption and immediately aborts the request.

[0091] If the upload has been sent, the returned data is stored in the Orphan Data Store, and a "save successful" UI prompt is not triggered.

[0092] In Embodiment 2, the asynchronous resource control method of this application saves upload bandwidth and avoids version rollback errors.

[0093] Example 3: In real-time monitoring dashboards, which contain dozens of charts, users can quickly switch between monitoring metrics (e.g., from CPU to memory). If a request for the old metric is returned, it can cause the charts to flicker or the data to become corrupted.

[0094] In Embodiment 3, the asynchronous resource control method of this application embodiment is used on the real-time monitoring screen. The asynchronous resource control method of this application embodiment is applied to the interruption-aware collaborative control layer, and its steps include: Switching metrics triggers startTransition.

[0095] The interruption-aware collaborative control layer creates an independent RCC for each chart's data request.

[0096] The old metric request was interrupted, and AbortController immediately terminated the HTTP connection.

[0097] For older requests that are already in flight, the returned data is marked as Task-Invalid and does not enter the ReduxStore. The main screen remains "loading" or displays cached data, effectively avoiding rendering of returned data (dirty data).

[0098] In Embodiment 3, the asynchronous resource control method of this application eliminates UI flickering caused by data backfilling and ensures data consistency.

[0099] Example 4: In search suggestions (e.g., e-commerce search boxes), when a user quickly types "React", requests R1("Re"), R2("Rea"), R3("Reac"), and R4("React") are generated. When the fourth character is entered, the responses to the first three requests may be delayed, causing the dropdown menu to flicker.

[0100] In Embodiment 3, during search association, the asynchronous resource control method of this application embodiment is used. The asynchronous resource control method of this application embodiment is applied to the interruption-aware collaborative control layer, and its steps include: Each key press triggers a new rendering task.

[0101] The interrupt-aware collaborative control layer maintains an RCC stack. When a new rendering task is generated, the RCC of the old rendering task is marked as INTERRUPTED.

[0102] Old requests related to old rendering tasks were cancelled in batches.

[0103] In Embodiment 4, the asynchronous resource control method of this application only processes the last input request, fundamentally solving the problem of flickering associated words and significantly reducing invalid network requests.

[0104] To verify the technical effect of the asynchronous resource control method of the present application embodiments, a test page simulating high-concurrency interaction was built under the same hardware environment (MacBookPro M1, 16GB RAM, Chrome 118) to test three modes: "asynchronous resource control method of the present application embodiments", "useEffect cleanup of related technologies", and "React Query caching strategy of related technologies".

[0105] Test Model: A data dashboard with 10 tabs is constructed. Each tab initiates 10 concurrent data requests (GET / api / data?id=N), with server response latency randomly distributed between 200ms and 800ms. An automated script switches tabs every 500ms for 30 seconds, resulting in approximately 60 tab switching operations.

[0106] Measurement tools: Memory peaks were sampled using the Chrome DevTools Memory panel (taking the maximum value from 3 samples); network request counts were intercepted and counted using Service Worker; main thread blocking time was accumulated using the longTask entries of the Performance API; UI flicker rate was counted using a screenshot comparison algorithm (pixel difference rate >5% is considered flicker).

[0107] Control variables: All three modes use the same component structure, the same API endpoints, and the same state management scheme (Zustand). The only difference is the control strategy for asynchronous resources.

[0108] Three independent tests were conducted on each of the three modes, and the median of the three independent tests was taken. The specific test data for the three modes are shown in Table 1.

[0109] Table 1:

[0110] According to the data in Table 1, the bandwidth consumption of the asynchronous resource control method in the application embodiment is not strictly 0KB, because the sent TCP connection will generate an RST packet (about tens of bytes) when it aborts, but this is negligible in terms of the amount of business data. The memory peaks of "useEffect cleanup in related technologies" and "React Query caching strategy in related technologies" include callback closures of delayed responses and unconsumed Promise chains. The asynchronous resource control method in the application embodiment avoids the accumulation of these objects by timely aborting.

[0111] The asynchronous resource control method in this application avoids memory consumption by callback functions and closures of asynchronous requests through immediate termination and isolation. The peak memory usage is significantly lower than that of "useEffect cleanup in related technologies" and "React Query caching strategies in related technologies". "useEffect cleanup in related technologies" and "React Query caching strategies in related technologies" increase GC pressure due to lingering Promise chains. Although React Query reduces the number of requests through cache reuse, the cached objects themselves still consume memory.

[0112] The asynchronous resource control method in this application completely intercepts invalid requests, while React Query, relying on a caching strategy, will still issue some requests (when the cache misses). The advantages of this asynchronous resource control method are most significant in high-frequency interaction scenarios involving "rapid and continuous switching." In such scenarios, it reduces invalid network bandwidth usage, lowers the main thread lag rate (improves FPS stability), saves client memory resources, and significantly improves asynchronous resource efficiency. In low-frequency operation scenarios, the differences between the three solutions are minimal.

[0113] The asynchronous resource control method in this application eliminates the state pollution problem caused by delayed data backfilling. During the test, the UI rendering frame rate (FPS) remained stable in the range of 58-60fps with no obvious frame drops, thus improving application stability.

[0114] Corresponding to the aforementioned application function implementation method embodiments, this application also provides an asynchronous resource control system, electronic device, and corresponding embodiments.

[0115] Figure 3 This is a schematic diagram of the asynchronous resource control system shown in the embodiments of this application.

[0116] See Figure 3 An asynchronous resource control system includes a context acquisition unit 301, an instruction generation unit 302, and a resource recycling unit 303.

[0117] The context acquisition unit 301 is used to acquire the resource control context of the rendering task. The resource control context includes the identifier of the rendering task, the rendering task status, the controller set, and the data storage area.

[0118] In one embodiment, when the interruptible rendering engine starts rendering a rendering task, a task start notification (onTaskStart) is issued first. When the context acquisition unit 301 receives the task start notification (onTaskStart), it can acquire the resource control context (RCC) of the rendering task. The resource control context may include the identifier (TaskID) of the rendering task, the status of the rendering task, the controller set (controllerSet), and the data storage area (dataStore).

[0119] The instruction generation unit 302 is configured to generate an interrupt instruction, including an identifier, if it is determined, based on the rendering task's scheduling notification and the set of controllers in the resource control context obtained by the context acquisition unit 301, that the rendering task has been interrupted. In one embodiment, during the rendering process of the interruptible rendering engine for a rendering task, if the interruptible rendering engine receives a higher-priority rendering task, it issues a rendering task scheduling notification "The rendering task has ended scheduling". The rendering task scheduling notification may include the identifier of the rendering task. The instruction generation unit 302 obtains a resource control context including the identifier of the rendering task based on the rendering task scheduling notification "The rendering task has ended scheduling". Based on the controller signal (AbortSignal) in the controller set of the resource control context, it determines whether the asynchronous operation associated with the controller has been completed. If the asynchronous operation associated with the controller has not been completed, it determines that the rendering task has been interrupted and generates an interrupt instruction including the identifier of the rendering task.

[0120] Resource reclamation unit 303 is used to delete the resource control context object corresponding to the resource control context and release memory in response to the interrupt instruction generated by instruction generation unit 302.

[0121] In one embodiment, the resource reclamation unit 303 may respond to an interrupt command including an identifier of a rendering task, obtain a resource control context including the identifier of the rendering task in the interrupt command, delete the resource control context object corresponding to the resource control context, and release the memory occupied by the resource control context, so as to reclaim the memory resources occupied by the resource control context in a timely manner.

[0122] The technical solution of this application embodiment, based on the resource control context of the rendering task of the interruptible rendering engine, listens for or infers the rendering task interruption event (distinct from the component unloading event) when the rendering task of the interruptible rendering engine is interrupted, and drives the application layer resource reclamation based on the rendering task interruption event, thereby realizing cross-layer event-driven asynchronous resource control between the "interruptible rendering engine scheduling layer" and the "application business logic layer". This achieves an asynchronous resource control that is independent of the interruptible rendering engine and not bound to the implementation details of the interruptible rendering engine, enabling deterministic control of asynchronous resources and significantly reducing the risk of asynchronous resource leakage.

[0123] Figure 4 This is another schematic diagram of the asynchronous resource control system shown in the embodiments of this application.

[0124] See Figure 4 An asynchronous resource control system includes a context acquisition unit 301, an instruction generation unit 302, a resource recycling unit 303, an abort unit 404, and a data processing unit 405.

[0125] The context acquisition unit 301 is used to generate an identifier for the rendering task and create a resource control context object for the rendering task when a task start notification for the rendering task is received; acquire the asynchronous operation of the rendering task, create a controller for the asynchronous operation, and write the controller's signal into the calling function of the asynchronous application programming interface, wherein the asynchronous operation is a specific execution instance formed after the asynchronous application programming interface is called; write the controller into the controller collection, write the identifier and the rendering task status into the resource control context object, and establish an implicit association between the identifier and the asynchronous operation in the data storage area to acquire the resource control context of the rendering task.

[0126] The instruction generation unit 302 is configured to: if it is determined from the scheduling notification of the rendering task that the scheduling of the rendering task has ended, then obtain the signal of the controller in the controller set; if it is determined from the signal that the asynchronous operation associated with the controller has not been completed, then determine that the rendering task has been interrupted; and if it is determined that the rendering task has been interrupted, then generate an interrupt instruction including an identifier.

[0127] The abort unit 404 is configured to, in response to an interrupt instruction, obtain a resource control context including the identifier according to the identifier included in the interrupt instruction; update the rendering task status of the resource control context including the identifier to be interrupted; obtain the signals of the controllers in the controller set according to the controller set of the resource control context; obtain the calling function of the asynchronous application programming interface including the signal according to the signal of the controller in the controller set; and abort the asynchronous side effects corresponding to the calling function according to the calling function of the asynchronous application programming interface including the signal.

[0128] The data processing unit 405 is used to obtain the identifier included in the returned data; obtain the resource control context including the identifier based on the identifier; if the rendering task status of the resource control context including the identifier is interrupted, mark the returned data and the metadata of the returned data as invalid data and store them in the data storage area.

[0129] Resource reclamation unit 303, in response to an interrupt instruction, when the main thread is idle, acquires the resource control context, including the identifier, from the resource control context stack; deletes the resource control context object, resource control context object reference, and / or the mapping entry between the identifier and the resource control context, thereby releasing memory; and / or deletes invalid data in the data storage area, as well as the storage reference storing invalid data, thereby releasing memory.

[0130] Regarding the system in the above embodiments, the specific manner in which each unit performs operations has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0131] Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0132] See Figure 5 The electronic device 1000 includes a memory 1010 and a processor 1020.

[0133] The processor 1020 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0134] Memory 1010 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 1020 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 1010 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 1010 may include removable storage devices that are readable and / or writable, such as laser discs (CDs), read-only digital multifunction optical discs (e.g., DVD-ROMs, dual-layer DVD-ROMs), read-only Blu-ray discs, ultra-high density optical discs, flash memory cards (e.g., SD cards, mini SD cards, Micro-SD cards, etc.), magnetic floppy disks, etc. Computer-readable storage media do not include carrier waves and transient electronic signals transmitted wirelessly or via wired connections.

[0135] The memory 1010 stores executable code, which, when processed by the processor 1020, can cause the processor 1020 to execute part or all of the methods described above.

[0136] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0137] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0138] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

[0139] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.< / controller>

Claims

1. An asynchronous resource control method, characterized by, include: Obtain the resource control context of the rendering task, wherein the resource control context includes the identifier of the rendering task, the rendering task status, the controller set, and the data storage area; If it is determined, based on the scheduling notification of the rendering task and the controller set, that the rendering task is interrupted, an interruption instruction including the identifier is generated. In response to the interrupt instruction, the resource control context object corresponding to the resource control context is deleted, and memory is released.

2. The method of claim 1, wherein, If, based on the scheduling notification of the rendering task and the controller set, it is determined that the rendering task is interrupted, an interruption instruction including the identifier is generated, comprising: If it is determined from the scheduling notification of the rendering task that the scheduling of the rendering task has ended, then obtain the signal of the controller in the controller set; If, based on the signal, it is determined that the asynchronous operation associated with the controller has not been completed, then it is determined that the rendering task has been interrupted. If it is determined that the rendering task has been interrupted, an interruption instruction including the identifier is generated.

3. The method of claim 2, wherein, Before deleting the resource control context object corresponding to the resource control context and releasing memory in response to the interrupt instruction, the process includes: In response to the interrupt instruction, the resource control context including the identifier is obtained based on the identifier included in the interrupt instruction; Update the rendering task status of the resource control context, including the identifier, to be interrupted; Based on the controller set of the resource control context, obtain the signals of the controllers in the controller set; Based on the signals from the controllers in the controller set, obtain the calling function of the asynchronous application programming interface that includes the signals; The asynchronous side effects corresponding to the called function are aborted based on the function call of the asynchronous application programming interface that includes the signal.

4. The method of claim 3, wherein, The method further includes: Obtain the identifier included in the returned data; Based on the identifier, obtain the resource control context including the identifier; If the rendering task status of the resource control context including the identifier is interrupted, the returned data and the metadata of the returned data are marked as invalid data and stored in the data storage area.

5. The method according to claim 4, characterized in that, The step of deleting the resource control context object corresponding to the resource control context and releasing memory in response to the interrupt instruction includes: In response to the interrupt instruction, when the main thread is idle, the resource control context including the identifier in the resource control context stack is obtained; Delete the resource control context object corresponding to the resource control context, the reference to the resource control context object, and / or the mapping entry between the identifier and the resource control context, and release memory; and / or, delete the invalid data in the data storage area, and the storage reference storing the invalid data, and release memory.

6. The method according to claim 3, characterized in that, The acquisition of the resource control context for the rendering task includes: Upon receiving the task start notification for the rendering task, an identifier for the rendering task is generated, and a resource control context object for the rendering task is created. Obtain the asynchronous operation for rendering the rendering task, create a controller for the asynchronous operation, and write the signal of the controller into the calling function of the asynchronous application programming interface, wherein the asynchronous operation is a specific execution instance formed after the asynchronous application programming interface is called; Write the controller to the controller set, write the identifier and the rendering task status to the resource control context object, establish an implicit association between the identifier and the asynchronous operation in the data storage area, and obtain the resource control context of the rendering task.

7. An asynchronous resource control system, characterized in that, include: The context acquisition unit is used to acquire the resource control context of the rendering task, wherein the resource control context includes the identifier of the rendering task, the rendering task status, the controller set, and the data storage area; The instruction generation unit is configured to generate an interruption instruction including the identifier if it is determined, based on the scheduling notification of the rendering task and the set of controllers in the resource control context obtained by the context acquisition unit, that the rendering task is interrupted. The resource reclamation unit is used to delete the resource control context object corresponding to the resource control context and release memory in response to the interrupt instruction generated by the instruction generation unit.

8. The system according to claim 7, characterized in that, The system also includes: A termination unit is configured to, in response to the interrupt instruction, obtain the resource control context including the identifier according to the identifier included in the interrupt instruction; update the rendering task status of the resource control context including the identifier to interrupted; obtain the signal of the controller in the controller set according to the controller set of the resource control context; obtain the calling function of the asynchronous application programming interface including the signal according to the signal of the controller in the controller set; and terminate the asynchronous side effect corresponding to the calling function according to the calling function of the asynchronous application programming interface including the signal.

9. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, It stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-6.

Images