A two-phase asynchronous task result proxy system and method suitable for heterogeneous interfaces

Abstract

This invention belongs to the field of computer software, and more specifically, relates to a two-stage asynchronous task result proxy method applicable to heterogeneous interfaces, comprising: a self-developed interface, a third-party interface, a third-party result container, a self-developed result container, and a third-party result proxy container; the self-developed interface module includes a self-developed abstract interface and a self-developed implementation interface; the self-developed implementation interface receives task A and task B; when task A is submitted, a self-developed result container object is created; the third-party interface is used to receive and execute task B; the self-developed result container is used to store the result of task A; the self-developed result container receives task B and calls the third-party interface; the third-party result container is used to receive the result of task B; the third-party result proxy container inherits from or implements the third-party result container in terms of type. This invention can seamlessly connect asynchronous tasks of two heterogeneous interfaces without requiring any modification to the proxied result container and its related libraries.

Description

Technical Field

[0001] This invention belongs to the field of computer software, and more specifically, relates to a two-stage asynchronous task result proxy system and method suitable for heterogeneous interfaces. Background Technology

[0002] With the expansion and popularization of computer and network technologies, computer networks play an indispensable role in people's learning, education, work, and life, gradually becoming a necessity. People's dependence on computer networks is increasing daily. In the field of modern computer software, cross-system tasks are quite common. These tasks usually involve a large amount of network I / O; therefore, executing these tasks asynchronously can effectively reduce resource overhead. In addition, there are also some asynchronous tasks within the system, which significantly improve performance compared to synchronous execution.

[0003] The widespread use of asynchronous tasks has also brought new challenges to the field of software technology, one of which is the monitoring and processing of task results.

[0004] In modern object-oriented programming languages ​​or libraries, the concept of a Future is commonly used. A Future represents a container for the result of a task. When a thread triggers (or submits) an asynchronous task, the called function synchronously returns a Future object. At this point, the Future does not contain the result of the task execution. After a certain period of time, other threads or other systems complete the task and set the task result into the Future. From then on, any access to the Future can retrieve the result of the task.

[0005] Many programming languages ​​and libraries also have methods for executing multiple tasks sequentially and returning a final Future. However, monitoring, passing, and processing the results of asynchronous tasks between heterogeneous libraries or interfaces, such as between a self-developed library and the standard toolkit of a programming language, is an issue that urgently needs to be addressed. Summary of the Invention

[0006] This invention proposes a two-stage asynchronous task result proxy system and method suitable for heterogeneous interfaces, with typical application scenarios as follows:

[0007] Submit an asynchronous task Task_A to the self-developed interface, specifying that upon completion of Task_A, an asynchronous task Task_B will be submitted to the third-party interface. Task_A should synchronously return a Future_B object. Here, the self-developed interface represents an asynchronous task interface developed using the method described in this invention. The third-party interface represents an asynchronous task interface from an existing standard library or other open-source library. Task represents a function, function pointer, or strategy object, depending on the programming language used. Future represents a container for the result of the asynchronous task.

[0008] The method described in this invention is the implementation of a self-developed interface and its associated components.

[0009] The detailed technical solution of this invention is as follows:

[0010] A two-stage asynchronous task result proxy system and method suitable for heterogeneous interfaces, characterized in that it includes: a self-developed interface, a third-party interface, a third-party result container, a self-developed result container, and a third-party result proxy container;

[0011] The self-developed interface includes a self-developed abstract interface (Interface_A) and a self-developed implementation interface (A_Implement).

[0012] The self-developed abstract interface is used to submit task A and task B; when task A is submitted, a Future_A object is created, that is, a space is requested to store Future_A and returned synchronously; when task B is submitted, the submission operation is delegated to a third-party interface.

[0013] The third-party interface is used to submit and execute task B. When task B is submitted, the third-party interface implementation should synchronously return a Future_B object.

[0014] The self-developed result container is used to store the results generated by task A, and also records the next task to be executed after the result is generated, i.e., task B. If no result has been generated in the self-developed result container, and an attempt is made to retrieve the task result, a null pointer or a conditionally suspended thread will be returned.

[0015] The third-party result container is used to store the results of task B;

[0016] The third-party result proxy container contains a third-party result container and inherits or implements the Future_B type of the third-party result container; it is used to adapt the third-party result container to the self-developed interface.

[0017] Furthermore, the self-developed abstract interface includes the Interface_A.submit function:

[0018] The Interface_A.submit function is used to receive task A and task B, and the return value of this function is of type Future_B.

[0019] The self-developed implementation interface is used to implement the Interface_A.submit function.

[0020] The `Interface_A.submit` function executes two asynchronous tasks sequentially: task A is executed first, and task B is executed after task A is completed. Task A can be directly handled by a self-developed interface; task A can be a function, function pointer, strategy object, or other types supported by the programming language. Task B can be handled by a third-party interface; the specific form of task B is defined by the third-party library (standard library or other open-source library).

[0021] Furthermore, the self-developed result container includes:

[0022] The Future_A.state field is used to mark whether a result has been produced in this container (because the task result may be a null pointer, so a separate flag field is necessary to determine whether the container has produced a result).

[0023] The Future_A.result field is used to store the task result, and its type can be any type.

[0024] The Future_A.next field is used to record the second task that needs to be executed after this container produces a result; its type is Task_B.

[0025] The Future_A.future field is used to store the proxy object of Future_B, that is, to store FutureProxy, and its type is FutureProxy.

[0026] The Future_A.set function is used to set the result for this container. This function takes one argument, which can be of any type.

[0027] Furthermore, the third-party result proxy container includes:

[0028] The FutureProxy.future field is used to store the container of the proxied third-party result, and its type is Future_B;

[0029] The FutureProxy.set function is used to set the container for the proxied third-party results. This function accepts one parameter of type Future_B.

[0030] The FutureProxy.get function is used to retrieve the task results from the proxied third-party result container. The return type of this function can be any type.

[0031] Furthermore, the third-party result container includes:

[0032] The Future_B.get function is used to retrieve the result of task B.

[0033] Preferably, the execution flow of the Future_A.set function is as follows:

[0034] a1 sets the Future_A.state field from 0 to 1, indicating that this container has produced a result;

[0035] a2, assign the result of Task 1 to the Future_A.result field;

[0036] a3, insert a complete memory barrier or insert equivalent code;

[0037] a4 calls the submit function of the third-party interface to submit task B in the Future_A.next field. If task B requires the result of task A, the Future_A.result field is first passed to task B in a known supported way, and the call to the Interface_B.submit function will synchronously return a Future_B object;

[0038] a5. Obtain the FutureProxy object from the Future_A.future field, call the FutureProxy.set function of the FutureProxy object, and pass the Future_B object returned in step a4 as the parameter.

[0039] The execution flow of the A_Implement.submit function is as follows:

[0040] b1 checks two tasks, A and B. If either task is a null pointer, the program terminates.

[0041] b2, create a Future_A object (a container for self-developed results) and pass in task B;

[0042] b3 executes task A in a known way, makes task A produce results, and calls the self-developed result container created by b2 with the results as parameters;

[0043] b4, retrieve the Future_A.future field of the Future_A object created in step b2, which is a FutureProxy object;

[0044] b5 returns the FutureProxy object obtained in step b4;

[0045] b6. When task A executed in step b3 produces a result, the Future_A.set function of the Future_A object (a self-developed result container) will be called with this result as a parameter.

[0046] Furthermore, the execution flow of the FutureProxy.set function is as follows:

[0047] c1 checks the parameter; if it is a null pointer, the program terminates.

[0048] c2 assigns the input parameter (a Future_B object) to the FutureProxy.future field;

[0049] c3, insert a complete memory barrier or insert equivalent code;

[0050] c4 performs the equivalent operation when Future_B (a third-party result container) produces results.

[0051] Furthermore, the execution flow of the FutureProxy.get function is as follows:

[0052] d1, insert a complete memory barrier or insert equivalent code;

[0053] d2 reads the FutureProxy.future field, which holds a Future_B object. If a null pointer is encountered, the equivalent operation to be performed if Future_B has not yet produced a result is executed.

[0054] d3, call the Future_B.get function of the Future_B object read in step d2, and return the result of the call.

[0055] The equivalent operations described in d2 include, but are not limited to: suspending the thread and returning a null pointer.

[0056] The technical advantages of this invention are:

[0057] 1. This invention provides a two-stage asynchronous task result proxy system and method applicable to heterogeneous interfaces. It can seamlessly connect asynchronous tasks of two heterogeneous interfaces without requiring any modification to the proxied result container and its related libraries.

[0058] 2. This invention provides a two-stage asynchronous task result proxy system and method suitable for heterogeneous interfaces. It does not restrict the design and implementation of third-party libraries. Other asynchronous task result proxy methods may require specific third-party libraries or require them to conform to specific interface specifications. The requirement for third-party libraries in this design method is logically mandatory. Without the submit function of interface B, the task cannot begin asynchronous execution; without Future_B, the task result cannot be obtained.

[0059] 3. This invention provides a two-stage asynchronous task result proxy system and method suitable for heterogeneous interfaces, which provides developers with sufficient design space. Other asynchronous task result proxy methods may have requirements on the form or execution method of the task.

[0060] 4. This invention provides a two-stage asynchronous task result proxy system and method suitable for heterogeneous interfaces, which can ensure thread safety. Memory barriers are used in many places in the method, and developers can also remove memory barriers that they consider unnecessary to improve performance. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of a UML class in Embodiment 1 of the present invention.

[0062] Figure 2 This is a flowchart (left) of Embodiment 1 of the present invention.

[0063] Figure 3 This is a flowchart (right) of Embodiment 1 of the present invention. Detailed Implementation

[0064] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0065] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0066] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0067] Where there is no conflict, the embodiments and features described herein can be combined with each other.

[0068] Example 1

[0069] This embodiment provides a proxy system for the results of two-stage asynchronous tasks with heterogeneous interfaces, combined with... Figure 1 As shown, it includes: a self-developed interface, a third-party interface (Interface_B), a third-party result container (Future_B), a self-developed result container (Future_A), and a third-party result proxy container (FutureProxy); the self-developed interface includes a self-developed abstract interface (Interface_A) and a self-developed implementation interface (A_Implement).

[0070] The Interface_A receives Task_A and Task_B and transmits them to A_Implement for processing. When Task_A is submitted, a Future_A object is created, which means allocating space to store Future_A (similarly, a Future_B object is created, which means allocating space to store Future_B; a FutureProxy object is created, which means allocating space to store FutureProxy).

[0071] The Interface_B is used to submit and execute Task_B.

[0072] The Future_A is used to store the result generated by Task_A, and also records the next task to be executed after the result is generated, namely Task_B. If an attempt is made to obtain the task result before a result is generated in Future_A, a null pointer or a conditionally suspended thread will be returned. The Future_A is also used to receive Task_B and call Interface_B with Task_B as a parameter.

[0073] The Future_B is used to store the result of Task_B.

[0074] The FutureProxy stores Future_B and inherits or implements Future_B in terms of type, and is used to observe whether the final Task_B is completed.

[0075] Furthermore, the self-developed abstract interface also includes:

[0076] The submit function, or Interface_A.submit, is used to receive Task_A and Task_B, and the return value of this function is of type Future_B.

[0077] The A_Implement is used to implement Interface_A.submit.

[0078] The `Interface_A.submit` method executes two asynchronous tasks sequentially: Task_A is executed first, and Task_B is processed after Task_A is completed. Task_A is the task directly processed by `A_Implement`, and its specific form can be a function, function pointer, strategy object, or other parameter types supported by the programming language. Task_B is the task that can be processed by `Interface_B`, and its specific form is defined by the corresponding third-party database.

[0079] Furthermore, the Future_A includes:

[0080] The Future_A.state field is used to mark whether a result has been produced in this container (because the task result may be a null pointer, so a separate flag field is necessary to determine whether the container has produced a result).

[0081] The Future_A.result field is used to store the task result, and its type can be any type.

[0082] The Future_A.next field is used to record the second task that needs to be executed after this container produces a result; its type is Task_B.

[0083] The Future_A.future field is used to store the proxy object of Future_B, that is, to store FutureProxy, and its type is FutureProxy.

[0084] The Future_A.set function is used to set the result for this container. This function takes one argument, which can be of any type.

[0085] Furthermore, the FutureProxy includes:

[0086] The FutureProxy.future field is used to store the proxied Future_B, and its type is Future_B.

[0087] The FutureProxy.set function is used to set the container for the proxied result. This function takes one parameter of type Future_B.

[0088] The FutureProxy.get function is used to retrieve the task results from the proxied Future_B. The return type of this function can be any type.

[0089] Furthermore, the Future_B includes:

[0090] The Future_B.get function is used to retrieve the result of Task_B.

[0091] Preferably, the execution flow of the Future_A.set function is as follows:

[0092] a1 sets the Future_A.state field from 0 to 1, indicating that this container has produced a result;

[0093] a2, assign the result of Task_A to the Future_A.result field;

[0094] a3, insert a complete memory barrier or insert equivalent code;

[0095] a4, calling Interface_B, specifically the Interface_B.submit function, submits Task_B of the Future_A.next field. If Task_B requires the result of Task_A, the Future_A.result field is first passed to Task_B using a known supported method. The call to Interface_B.submit will synchronously return a Future_B object.

[0096] a5. Get the FutureProxy of the Future_A.future field, call the second set function of FutureProxy, and pass the Future_B object returned in step a4 as the parameter.

[0097] Furthermore, the execution flow of A_Implement.submit is as follows:

[0098] b1, check both Task_A and Task_B. If either one is a null pointer, terminate the program.

[0099] b2, create a Future_A object and pass in Task_B;

[0100] b3 executes Task_A in a known manner. Task_A produces a result, and the result is used as a parameter to call the Future_A.set function of the Future_A object created by b2.

[0101] b4, retrieve the future field of Future_A created in step b2, which is a FutureProxy object;

[0102] b5 returns the FutureProxy object obtained in step b4;

[0103] Furthermore, the execution flow of the FutureProxy.set function is as follows:

[0104] c1 checks the parameter; if it is a null pointer, the program terminates.

[0105] c2 assigns the input parameter to the FutureProxy.future field;

[0106] c3, insert a complete memory barrier or insert equivalent code;

[0107] c4 performs the equivalent operation when Future_B produces a result.

[0108] Furthermore, the execution flow of the FutureProxy.get function is as follows:

[0109] d1, insert a complete memory barrier or insert equivalent code;

[0110] d2 reads the FutureProxy.future field. If a null pointer is encountered, perform the equivalent operation as if Future_B had not yet produced a result.

[0111] d3, call the Future_B.get function of the Future_B object read in step d2, and return the result of the call.

[0112] Furthermore, the equivalent operations include, but are not limited to: suspending the thread and returning a null pointer.

[0113] An implementation method for a two-phase asynchronous task result proxy system suitable for heterogeneous interfaces. Figure 2 , Figure 3 include:

[0114] The self-developed interface receives Task A and Task B and transmits them to the self-developed implementation interface:

[0115] The self-developed submit function of the interface receives task A, calls the thread to execute task A, and transmits task B to the Future_A.next field of the self-developed result container; when task A is completed, the result of task A is used as a parameter to call the Future_A.set function of the self-developed result container.

[0116] The Future_A.set function of the self-developed result container calls the submit function of the third-party interface to execute task B and receive the result; when task B is submitted, a Future_B object is obtained synchronously, this Future_B object is saved as a parameter in the FutureProxy.future field, and the FutureProxy.set function is called.

[0117] The submit function of the third-party interface module executes task B and transmits the result of task B to the third-party result container.

[0118] The FutureProxy.get function of the third-party result proxy container retrieves the result of task B from the third-party result container;

[0119] FutureProxy inherits from or in type Future_B.

[0120] The specific process is as follows:

[0121] 1. Define Task A: Task_A and Task B: Task_B;

[0122] 2. Using Task_A and Task_B from step 1 as the first and second parameters respectively, call the self-developed interface. This will actually call the A_Implement.submit function of A_Implement. The specific execution steps are as follows:

[0123] 2.1. Check that the two input parameters are Task_A and Task_B. If either one is a null pointer, terminate the current program. If neither is a null pointer, continue the next operation.

[0124] 2.2. Create a Future_A object, wherein Future_A includes:

[0125] The Future_A.state field is used to indicate whether a result has been produced in this container;

[0126] The Future_A.result field is used to store the task result;

[0127] The Future_A.next field is used to record the Task_B that needs to be executed after this container produces a result;

[0128] The Future_A.future field is used to store the proxy object of Future_B, that is, to store FutureProxy;

[0129] The Future_A.set function is used to set the result for this container. This function takes one argument, which can be of any type.

[0130] 2.3. Pass Task_B to the Future_A.next field;

[0131] 2.4. Call A_Implement.submit and execute Task_A in a known manner. After Task_A produces a result, call the Future_A.set function created in step 2.2 with the result of Task_A as the parameter; (Task_A can be executed by starting a new thread or by taking a thread from a thread pool).

[0132] 2.5. The submit function of A_Implement (self-developed implementation interface) obtains the future field of Future_A (self-developed result container) created in step 2.2, and creates a FutureProxy (FutureProxy).

[0133] 2.6. Return the FutureProxy object created in step 2.5.

[0134] 3. After Task_A is executed, the A_Implement.submit function of A_Implement calls the Future_A.set function of Future_A with the result of Task_A as the parameter. The specific execution steps of Future_A.set are as follows:

[0135] 3.1. Set the Future_A.state field from 0 to 1 to indicate that Future_A has produced a result;

[0136] 3.2. Assign the input parameter (i.e., the result of Task_A) to the Future_A.result field;

[0137] 3.3. Insert a complete memory barrier or insert equivalent code;

[0138] 3.4. Call the Interface_B.submit function and submit Task_B of the Future_A.next field to Interface_B;

[0139] 3.5. If the execution of Task_B requires the result of Task_A, then the content of the Future_A.result field is used to pass the result of Task_A to Task_B in a known way;

[0140] 3.6. The Interface_B.submit function of Interface_B executes Task_B and returns a Future_B object. (Interface_B is a third-party standard library or a known library, which is not within the scope of this invention and is considered a known entity.)

[0141] 3.7. Obtain the FutureProxy of the Future_A.future field, call the FutureProxy.set function, and pass the Future_B object returned in step 3.6 as the parameter.

[0142] 3.8. The FutureProxy.set function receives Future_B and passes Future_B to the FutureProxy.future field for proxying.

[0143] 4. After Task_B is executed, the result of Task_B is set in Future_B (Future_B), which is a result container of a third party or standard library, as an existing result container.

[0144] 5. At this point, the `get` function of `FutureProxy` is called. The execution flow of the `get` function is as follows:

[0145] 5.1 Insert a complete memory barrier or insert equivalent code.

[0146] 5.2 Read the FutureProxy.future field.

[0147] 5.3 If a null pointer is read, perform the equivalent operation as if Future_B had not yet produced a result, such as returning a null pointer or conditionally suspending the thread. Otherwise, proceed to step 5.4.

[0148] 5.4 Call step 5.2 to read the Future_B proxied by the FutureProxy.future field.

[0149] 5.5 Return the result of step 5.3 or 5.4, i.e., display the final result.

[0150] 6. If the FutureProxy.get function is called before Task_A is completed, that is, before Future_B exists, then the same phenomenon as when calling Future_B but getting no result will occur, as described in step 5.3.

[0151] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the technical solution of the present invention, and are not intended to limit the specific implementation of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the claims of the present invention should be included within the protection scope of the claims of the present invention.

Claims

1. A two-stage asynchronous task result proxy system suitable for heterogeneous interfaces, characterized in that, include: Self-developed interfaces, third-party interfaces, third-party result containers, self-developed result containers, and third-party result proxy containers; The self-developed interface includes a self-developed abstract interface and a self-developed implementation interface; The self-developed abstract interface receives task A and task B and transmits them to the self-developed implementation interface for processing; when task A is submitted, a self-developed result container object is created. The self-developed result container calls a third-party interface, which is used to receive and execute task B. The self-developed result container is used to receive and execute task A and store the results, store task B and trigger the submission of task B; The third-party result container is used to receive the results of task B; The third-party result proxy container inherits from or implements the third-party result container in terms of type; The third-party result proxy container has a field for storing the third-party result container; The self-developed result container includes: The Future_A.state field is used to indicate whether a result has been produced in this container; The Future_A.result field is used to store the task result; The Future_A.next field is used to record task B that needs to be executed after this container produces a result; The Future_A.future field is used to store the result container proxy for the second task; The Future_A.set function is used to set the result for this container. This function takes one argument, which can be of any type. The third-party result proxy container includes: The FutureProxy.future field is used to store third-party result container objects; The FutureProxy.set function is used to set the container for the proxied result; The FutureProxy.get function is used to retrieve the task results from the proxied result container.

2. The two-stage asynchronous task result proxy system for heterogeneous interfaces according to claim 1, characterized in that, The self-developed interface also includes: The Interface_A.submit function is used to receive and execute task A and task B in sequence. The self-developed implementation interface is used to implement the Interface_A.submit function.

3. The two-stage asynchronous task result proxy system for heterogeneous interfaces according to claim 1, characterized in that, The third-party result container includes: The Future_B.get function is used to retrieve the task results from the proxied result container.

4. The implementation method of a two-stage asynchronous task result proxy system suitable for heterogeneous interfaces as described in any one of claims 1-3, characterized in that, Includes the following steps: The self-developed interface receives Task A and Task B and transmits them to the self-developed implementation interface: The self-developed submit function of the interface receives task A, calls the thread to execute task A, and transmits task B to the Future_A.next field of the self-developed result container; when task A is completed, the result of task A is used as a parameter to call the Future_A.set function of the self-developed result container. The Future_A.set function of the self-developed result container calls the submit function of the third-party interface to execute task B and receive the result; after task B is submitted, a Future_B object is obtained synchronously. This Future_B object is used as a parameter to call the FutureProxy.set function and save it to the FutureProxy.future field. The submit function of the third-party interface module executes task B and transmits the result of task B to the third-party result container. The FutureProxy.get function of the third-party result proxy container retrieves the result of task B from the third-party result container.

5. The implementation method of a two-stage asynchronous task result proxy system suitable for heterogeneous interfaces according to claim 4, characterized in that, The execution flow of the Future_A.set function of the self-developed result container is as follows: a1 sets the state field from 0 to 1; a2 assigns the task result to the result field; a3, insert a complete memory barrier or insert equivalent code; a4 calls the submit function of the third-party interface module and submits task B in the next field to the third-party interface module. The third-party interface module returns a Future_B object. a5. Obtain the FutureProxy of the Future_A.future field of the self-developed result container, call the set function of FutureProxy, and pass the Future_B object returned in step a4 as the parameter.

6. The implementation method of a two-stage asynchronous task result proxy system suitable for heterogeneous interfaces according to claim 4, characterized in that, The execution flow of the Future_A.submit function of the self-developed result container is as follows: b1, check task A and task B. If either one is a null pointer, terminate the program. If neither is a null pointer, continue the next operation. b2, create a self-developed result container object; b3, pass task B to the Future_A.next field of the self-developed result container; b4, call the self-developed implementation interface and execute task A in a known way, and call the Future_A.set function of the self-developed result container created in step b2 with the result of task A as a parameter; b5. Obtain the Future_A.future field of the self-developed result container object created in step b2, and create a third-party result proxy container; b6, the submit function will synchronously return a Future_B object after being called; b7. When task A, executed in step b3, produces a result, the Future_A.set function of the self-developed result container will be called with this result as a parameter.

7. The implementation method of a two-stage asynchronous task result proxy system suitable for heterogeneous interfaces according to claim 4, characterized in that, The execution flow of the FutureProxy.get function of the third-party result proxy container is as follows: d1, insert a complete memory barrier or insert equivalent code; d2, read the FutureProxy.future field; d3. If a null pointer is read, perform the operation equivalent to the operation performed when the third-party result container has not yet produced a result; otherwise, execute step d4. d4 calls the Future_B.get function to retrieve the task results from the third-party result container and returns the result.

8. The implementation method of a two-stage asynchronous task result proxy system suitable for heterogeneous interfaces according to claim 7, characterized in that, The equivalent operations described in step d3 include, but are not limited to: suspending the thread and returning a null pointer.

Images