Cross-language task processing method and related equipment

Abstract

The invention discloses a cross-language task processing method and related equipment, and the method comprises the steps: obtaining a to-be-executed coroutine task of a task scheduling framework of a bottom layer; the coroutine task comprises an asynchronous function, and the task scheduling framework and the asynchronous function are compiled by adopting different programming languages; constructing a wakeup device of an asynchronous function according to a task handle of the coroutine task; and according to the wake-up device, calling a polling method of an asynchronous function to poll the coroutine task and processing a return result of the polling method. According to the embodiment of the invention, the Rust asynchronous primitive can be matched with the underlying task scheduling framework of other languages, so that various services of different languages can share the same task scheduling framework, and unified management of thread resources is realized.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a cross-language task processing method and related equipment. Background Art

[0002] Rust is an emerging programming language that provides keywords and structure definitions for asynchronous programming. However, Rust does not come with an asynchronous scheduling framework, which means that developers need to implement their own scheduling framework or use Rust's open source scheduling framework. Since Rust cannot directly reuse the scheduling capabilities implemented in other languages, in some development scenarios, Rust asynchronous tasks are not compatible with the scheduling frameworks of other languages. Summary of the invention

[0003] The embodiments of the present application provide a cross-language task processing method and related equipment, which can adapt Rust asynchronous primitives to the underlying task scheduling frameworks of other languages, so that various services in different languages ​​can share the same task scheduling framework and realize unified management of thread resources.

[0004] In the first aspect, an embodiment of the present application provides a cross-language task processing method, which is applied to an electronic device. The electronic device obtains the coroutine task to be executed by the task scheduling framework from the task queue of the underlying task scheduling framework; the coroutine task is obtained by encapsulating the asynchronous function, and the task scheduling framework and the asynchronous function are written in different programming languages. The electronic device uses the task handle of the coroutine task as the parameter of the wakeup of the asynchronous function to construct the wakeup, and passes the wakeup into the polling method of the asynchronous function, and then calls the polling method to poll the coroutine task and process the return result of the polling method. Among them, the asynchronous function is written in Rust language.

[0005] It can be seen that in the embodiment of the present application, the electronic device encapsulates the asynchronous function on the Rust side as a coroutine task and gives it to the underlying task scheduling framework. When the bottom layer needs to call the polling method of the asynchronous function to poll the coroutine task, the awakener of the asynchronous function is constructed according to the task handle of the coroutine task in the task scheduling framework, so as to adapt the upper-level task wake-up logic to the task scheduling framework, so that the underlying task scheduling framework can call the upper-level method to promote the execution of the coroutine task. In this way, the Rust asynchronous primitive is adapted to the underlying task scheduling framework of other languages, and the upper-level asynchronous functions can be passed to the task scheduling framework as a task for execution, so that various services in different languages ​​can share the same task scheduling framework, realize the unified management of thread resources, and thus reduce the waste of thread resources.

[0006] In a possible implementation, the electronic device may also obtain a task scheduling function of a task scheduling framework, and use the task handle of the coroutine task and the task scheduling function of the task scheduling framework as parameters to construct a wakeup device.

[0007] In this implementation method, the task scheduling function of the underlying task scheduling framework and the task handle of the coroutine task on the task scheduling framework side are used as input parameters of the wakeup device, and an wakeup device associated with the asynchronous function is constructed, thereby achieving the adaptation of the underlying task scheduling framework and the upper-level wakeup device. When the electronic device calls the wakeup function in the wakeup device, it can allow the underlying task scheduling framework to re-execute the suspended task.

[0008] In a possible implementation, before obtaining the coroutine task to be executed by the underlying task scheduling framework, the electronic device will also obtain the asynchronous function submitted by the user through the interface provided by Rust, and then call the business logic submission interface of the task scheduling framework to obtain the business logic of the asynchronous function; the business logic includes the construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method. The electronic device encapsulates the obtained construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method into a function to be processed, and then encapsulates the function to be processed into a task structure of the task scheduling framework to obtain the coroutine task of the task scheduling framework.

[0009] In this implementation, the electronic device provides the interface in Rust to the user, and the user can submit the asynchronous function through the interface, and the business logic submission interface in the task scheduling framework is adapted to Rust, and it receives a method that carries the business logic. Through the business logic submission interface, the construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method can be obtained. These logics are abstractly encapsulated as a function to be processed, and further encapsulated as the task structure of the underlying task scheduling framework, that is, the asynchronous function is finally encapsulated as a coroutine task, so that all upper-level asynchronous functions can be passed to the scheduler of the task scheduling framework as a task for execution.

[0010] In one possible implementation, if the return result of the polling method indicates that the coroutine task is blocked, the electronic device will suspend the coroutine task and call the task state conversion interface of the task scheduling framework to set the state of the coroutine task to blocked. If the return result of the polling method indicates that the coroutine task is completed, the electronic device calls the task state conversion interface to set the state of the coroutine task to completed.

[0011] In this implementation, the electronic device promotes the execution of the coroutine task through the polling method of the asynchronous function scheduled by the underlying scheduler, and when the return result indicates that the coroutine task is blocked, the task state transition interface of the task scheduling framework is called to set the state of the coroutine task to blocked; when the return result indicates that the execution of the coroutine task is completed, the task state transition interface of the task scheduling framework is called to set the state of the coroutine task to completed, so that the underlying task scheduling framework can perceive the state of the coroutine task.

[0012] In a possible implementation, when the return result of the polling method indicates that the coroutine task is blocked, the electronic device will call the task acquisition interface of the task scheduling framework to obtain the wakeup device. When it is detected that the coroutine task is ready to be re-executed, the electronic device will call the task wakeup interface of the task scheduling framework to wake up the coroutine task through the wakeup function of the wakeup device.

[0013] In this implementation, although the logic of the wake-up mechanism is implemented on the Rust side, the task wake-up operation is actually performed through the task acquisition interface and task wake-up interface of the task scheduling framework, that is, task wake-up is implemented in the underlying task scheduling framework.

[0014] In one possible implementation, the asynchronous function in Rust is a function called by the target asynchronous function, and the task handle of the asynchronous function in Rust implements the await operation. When the return result of the polling method indicates that the coroutine task is executed, the electronic device returns the return result of the polling method to the task handle of the asynchronous function in Rust; and calls the task wake-up interface to use the wake-up device of the target asynchronous function to wake up the target asynchronous function. The wake-up device of the target asynchronous function is passed to the asynchronous function when executing the await operation of the task handle of the asynchronous function in Rust.

[0015] In this implementation, the electronic device returns the return result of the polling method in the task scheduling framework to the task handle of the asynchronous function in Rust, so that the target asynchronous function that calls the asynchronous function perceives that the asynchronous function has been executed. Then the task wakeup interface of the task scheduling framework is called to use the wakeup device of the target asynchronous function to wake up the target asynchronous function to avoid the target function being blocked.

[0016] In a possible implementation, the electronic device may call a task acquisition interface of a task scheduling framework to obtain a wakeup device of an asynchronous function from an input parameter of a polling method.

[0017] In this implementation, the input parameters of the polling method include the wakeup device of the asynchronous function. When returning the result, the polling method can also return the wakeup device in the input parameters to the task acquisition interface of the task scheduling framework. Then, when the coroutine task encounters a blockage, the electronic device may not save the wakeup device, and may obtain the wakeup device from the saved location when the coroutine task can be re-executed, thereby simplifying the entire wakeup process.

[0018] In the second aspect, the embodiment of the present application provides a cross-language task processing device, which includes an acquisition unit and a processing unit. The acquisition unit is used to acquire the coroutine task to be executed by the underlying task scheduling framework; the coroutine task includes an asynchronous function, and the task scheduling framework and the asynchronous function are written in different programming languages; the processing unit is used to construct a wakeup device of the asynchronous function according to the task handle of the coroutine task; according to the wakeup device, the polling method of the asynchronous function is called to poll the coroutine task and process the return result of the polling method.

[0019] In a possible implementation, the acquisition unit is further used to: acquire a task scheduling function of a task scheduling framework. In terms of constructing a wakeup of an asynchronous function according to the task handle of a coroutine task, the processing unit is specifically used to: construct a wakeup using the task handle of the coroutine task and the task scheduling function of the task scheduling framework as parameters.

[0020] In a possible implementation, the asynchronous function is written in Rust. The acquisition unit is also used to acquire the asynchronous function submitted by the user through the interface provided by Rust. The processing unit is also used to call the business logic submission interface of the task scheduling framework to acquire the business logic of the asynchronous function; the business logic includes the construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method; the construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method are encapsulated as a function to be processed; the function to be processed is encapsulated as a task structure of the task scheduling framework to obtain a coroutine task.

[0021] In a possible implementation, in processing the return result of the polling method, the processing unit is specifically used to: if the return result of the polling method indicates that the coroutine task is blocked, the coroutine task is suspended, and the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to blocked. If the return result of the polling method indicates that the coroutine task is executed, the task state conversion interface is called to set the state of the coroutine task to completed.

[0022] In a possible implementation, when the return result of the polling method indicates that the coroutine task is blocked, the processing unit is further used to: call the task acquisition interface of the task scheduling framework to obtain the wakeup device. When it is monitored that the coroutine task is ready to be re-executed, the task wakeup interface of the task scheduling framework is called to wake up the coroutine task through the wakeup function of the wakeup device.

[0023] In a possible implementation, the asynchronous function in Rust is a function called by the target asynchronous function, and the task handle of the asynchronous function in Rust implements the await operation. When the return result of the polling method indicates that the coroutine task is executed, the processing unit is also used to: return the return result of the polling method to the task handle of the asynchronous function in Rust; and call the task wake-up interface to wake up the target asynchronous function using the wake-up device of the target asynchronous function; the wake-up device of the target asynchronous function is passed to the asynchronous function when executing the await operation of the task handle of the asynchronous function in Rust.

[0024] In a possible implementation, in terms of calling the task acquisition interface of the task scheduling framework to obtain the wakeup device, the processing unit is specifically used to: call the task acquisition interface of the task scheduling framework to obtain the wakeup device of the asynchronous function from the input parameters of the polling method.

[0025] It can be understood that since the method embodiment and the device embodiment are different presentation forms of the same technical concept, the content of the first aspect of the embodiment of the present application should be synchronously adapted to the second aspect of the embodiment of the present application, and can achieve the same or similar beneficial effects, which will not be repeated here.

[0026] In a third aspect, an embodiment of the present application provides an electronic device, comprising a processor, a memory, and one or more programs, wherein the processor is connected to the memory, the one or more programs are stored in the memory, and are configured to implement the method in the first aspect when executed by the processor.

[0027] In a fourth aspect, an embodiment of the present application provides a chip, comprising: a processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes the method in the first aspect described above.

[0028] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program for execution by a device, and when the computer program is executed, implements the method in the first aspect as described above.

[0029] In a sixth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run by an electronic device, the electronic device executes the method in the first aspect as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0031] Figure 1 A schematic diagram of a processing flow of a task scheduling framework provided in an embodiment of the present application;

[0032] Figure 2 A schematic diagram of an overall architecture of cross-language adaptation provided in an embodiment of the present application;

[0033] Figure 3 A flowchart of a cross-language task processing method provided in an embodiment of the present application;

[0034] Figure 4 A schematic diagram of calling a wake-up device in a task scheduling framework provided in an embodiment of the present application;

[0035] Figure 5 A schematic diagram of a return result of a polling method provided in an embodiment of the present application;

[0036] Figure 6 A flowchart of another cross-language task processing method provided in an embodiment of the present application;

[0037] Figure 7 A schematic diagram of the overall process of a cross-language task processing method provided in an embodiment of the present application;

[0038] Figure 8 A schematic diagram of the structure of a cross-language task processing device provided in an embodiment of the present application;

[0039] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The terms "first", "second", "third" and "fourth" etc. in the specification and claims of the present application and the drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices.

[0041] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0042] The terms "component", "module", "system", etc. used in this specification are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program and / or a computer running on a processor. By way of illustration, both applications running on a terminal device and a terminal device can be components. One or more components can reside in a process and / or an execution thread, and a component can be located on a computer and / or distributed between two or more computers. In addition, these components can be executed from various computer-readable media having various data structures stored thereon. Components can, for example, communicate through local and / or remote processes according to signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system and / or a network, such as the Internet interacting with other systems through signals).

[0043] First, the relevant terms and related technical background in this application are briefly described to facilitate understanding by those skilled in the art.

[0044] (1) Rust: An emerging programming language released by Mozilla.

[0045] (2) Trait: A feature similar to interfaces in the Rust language that defines the functionality that a specific type may share with other types.

[0046] (3) Asynchrony: Asynchrony is usually opposite to synchronization. The caller will not be blocked immediately and wait for the other party to return the result, but will continue to run until the callee notifies the caller that the result is available, or handles the call through a callback function.

[0047] (4) Asynchronous Scheduling Framework (Async Runtime): The main body used to schedule asynchronous tasks, generally composed of multiple worker threads and task queues.

[0048] (5) Coroutine: A coroutine is a cooperative multitasking model that uses an asynchronous mechanism, allows multiple entry points, and can suspend and resume execution at specified locations.

[0049] (6) Stackless coroutine: Stackless coroutine does not use stack and context switching to execute asynchronously, but directly uses the system stack. It is essentially a state machine that only retains variables and temporary variables needed after recovery, stores the current state, and relies on the state to decide which part of the code to execute after recovery.

[0050] (7) Future: An interface definition in the Rust language that declares the methods and parameters that the stackless coroutine asynchronous type should define. Rust asynchronous functions all implement instances of this interface definition.

[0051] (8) Poll: declared in the Rust Future interface definition, it is used to promote asynchronous task execution when the Rust asynchronous scheduling framework executes tasks.

[0052] (9)Waker: Contains the wake function, which is responsible for waking up the corresponding asynchronous task, calling the corresponding poll method, continuing to run the state machine, and advancing the progress of task execution.

[0053] (10)async: A keyword in the Rust language. A function with the async keyword is an asynchronous function.

[0054] (11) Wait: For instances that implement Future, you can use this keyword to call the corresponding poll method at the bottom layer and wait for it asynchronously until the execution is completed and the result is returned.

[0055] In Rust, a function with the async keyword is called an asynchronous function, and its return value is actually an object that implements the Future Trait, which can be simply called Future, which is Rust's stackless coroutine. For example, the following is an example of an asynchronous function:

[0056]

[0057] In this example, "func", "mission1", "mission2", and "mission3" are asynchronous functions. Other asynchronous functions are called in "func", and the keyword await is used to indicate waiting for the execution result of the called asynchronous function. For each asynchronous function, the compiler will generate a generator state machine for it, and each await point in the function can be regarded as a state of the state machine. When the poll method of the asynchronous function "func" is called, it means that the asynchronous function starts to execute. When the await point is encountered during execution, the poll method of the corresponding asynchronous function "mission1", "mission2", and "mission3" will continue to be called, and the execution result will be obtained according to whether the current execution can be completed immediately. There are two possible return values: Ready and Pending. If Ready is returned, it means that the called asynchronous function has been executed and the following function can be executed linearly. If Pending is returned, the state machine will record the current state (for example: blocked) and exit the execution of the current asynchronous function "func". At this time, the poll method of the "func" function will also return Pending. The next time the poll method of the "func" function is called, it will not start from the function entry, but from the await point where Pending was returned last time.

[0058] After an asynchronous function returns Pending, it will be permanently suspended. Therefore, when the task can continue to execute, the Waker associated with the asynchronous function needs to be used to wake up the task and finally execute it. For example, the following is an example of a Waker structure:

[0059]

[0060]

[0061] It should be understood that the Waker structure contains a data pointer and four function hooks, which take the data pointer as an input parameter. Among them, the wake function in the Waker (such as wake() or wake_by_ref()) is responsible for waking up the task.

[0062] Based on the functions implemented by the asynchronous primitives defined by Rust, some existing task scheduling frameworks will also choose Rust to implement the underlying scheduling. However, the Rust language cannot directly reuse the scheduling capabilities implemented by other languages, and it is difficult for other languages ​​to adapt to the primitives defined by Rust. On a multi-language system platform, services implemented in different languages ​​will have their own task scheduling frameworks. The existence of a multi-task scheduling framework means that each service has its own thread pool, making it difficult to uniformly manage the underlying thread pool, which will lead to the problem of thread resource waste. In addition, if the task scheduling framework also manages task priorities, the priorities between different services in different languages ​​will also be confusing.

[0063] The following is a brief description of the architecture to which this application can be applied.

[0064] See also Figure 1 , Figure 1 A schematic diagram of a processing flow of a task scheduling framework provided in an embodiment of the present application, such as Figure 1 As shown in the figure, the user submits the business logic through the electronic device, and the task scheduling framework encapsulates the business logic into a task, that is, generates a task. The task scheduling framework starts to execute the task at a certain time, and returns two results after execution. The first result is that the task is completed, and the second result is that the task is blocked. When the task is blocked, the task scheduling framework needs to wake up the task and execute it again until the task is completed.

[0065] Based on the processing flow of the abstracted task scheduling framework, the embodiment of the present application makes a one-to-one correspondence between the processing flow of Rust asynchronous tasks and the processing flow of the underlying task scheduling framework, as shown in the following table:

[0066]

[0067] Based on the above one-to-one processing flow, the present application embodiment provides an overall architecture for cross-language adaptation. Figure 2 , Figure 2 A schematic diagram of an overall architecture of cross-language adaptation provided in an embodiment of the present application is shown in FIG. Figure 2 As shown in Figure 1, the architecture includes the Rust Application Programming Interface (API) layer, the Rust adaptation layer, the southbound interface layer, and the underlying scheduling layer. The task scheduling framework used in the scheduling layer provides a business logic submission interface, a task acquisition interface, a task wakeup interface, and a task state conversion interface in the southbound interface layer.

[0068] Business logic submission interface, used by users to submit business logic and generate corresponding tasks based on the business logic;

[0069] Task acquisition interface, used to pass in the Waker associated with the Rust asynchronous function;

[0070] Task wakeup interface, used to specify the task that needs to be woken up and re-executed;

[0071] The task state conversion interface is used by the task scheduling framework to perceive the result of polling the asynchronous function and obtain the current state of the task.

[0072] Figure 2 In the architecture shown, the task scheduling framework used by the scheduling layer is the scheduling framework of other languages, and the external API is still provided by Rust. In the Rust adaptation layer, the Rust asynchronous primitives are adapted to the interface provided by the task scheduling framework (for example: building a Waker for an asynchronous function), and the asynchronous function or asynchronous task is executed by calling the interface in the southbound interface layer, and finally the user calls the interface provided by the task scheduling framework through the Rust API layer and the Rust adaptation layer. The purpose. Based on this architecture, the core idea of ​​this application is to abstract the call of the Future object into a general function pointer, so that it can be taken over by other schedulers as a task and execute the corresponding asynchronous function or asynchronous task. At the same time, the Waker of the asynchronous function is adapted to the underlying task scheduling framework, so that the Waker of the asynchronous function can wake up the task that needs to be re-executed in the underlying scheduler.

[0073] The technical solution provided by this application is introduced in detail below in conjunction with specific implementation methods.

[0074] See also Figure 3 , Figure 3 A flow chart of a cross-language task processing method provided in an embodiment of the present application, which can be based on Figure 2 The architecture shown is implemented and can be executed by an electronic device. Figure 3 As shown, the method includes steps 301-303:

[0075] 301: Obtain the coroutine task to be executed by the underlying task scheduling framework; the coroutine task includes an asynchronous function, and the task scheduling framework and the asynchronous function are written in different programming languages.

[0076] In the embodiment of the present application, the coroutine task is obtained by encapsulating an asynchronous function. For example, the asynchronous function (also called an asynchronous task) can be a Future written by the user in the Rust language. For example, an example of implementing Future on a Generator structure is given below:

[0077]

[0078] Exemplarily, the user submits an asynchronous function through the interface provided by Rust. The asynchronous function can be a sub-function of an asynchronous function, such as "mission1", "mission2", "mission3" in the previous example, or a parent asynchronous function, such as "func" in the previous example. For an asynchronous function, it must have corresponding business logic, and the electronic device obtains the business logic of the asynchronous function through the business logic submission interface provided by the task scheduling framework. Exemplarily, the business logic may include the construction logic of the Waker associated with the asynchronous function, the execution logic of the poll method of the asynchronous function, and the processing logic of the return result of the poll method. The business logic submission interface on the task scheduling framework side is connected to the Rust side, so for the business logic submission interface, what it obtains is the business logic of the asynchronous function. The electronic device encapsulates the construction logic of the Waker associated with the asynchronous function, the execution logic of the poll method of the asynchronous function, and the processing logic of the return result of the poll method as a function to be processed, applies the function to be processed to the stack, and gives the function pointer of the function to be processed to the task scheduling framework. The task scheduling framework encapsulates the function pointer as a member variable to obtain its own task structure, thereby generating a coroutine task to be executed by the task scheduling framework.

[0079] In this implementation, the electronic device provides the interface in Rust to the user, and the user can submit the asynchronous function through the interface. The business logic submission interface in the task scheduling framework is adapted to Rust, and it receives a method that carries the business logic. Through the business logic submission interface, the Waker construction logic, the poll method execution logic, and the poll method return result processing logic can be obtained. These logics are abstractly encapsulated as a function to be processed, and further encapsulated as the task structure of the underlying task scheduling framework, that is, the asynchronous function is finally encapsulated as a coroutine task, so that all upper-level asynchronous functions can be passed to the task scheduling framework scheduler as a task for execution.

[0080] It should be understood that the coroutine task is essentially a stackless coroutine. If the task scheduling framework is a stacked coroutine, then for the underlying task scheduling framework, there is no need to allocate stack space for the coroutine task and switch to the stacked coroutine. When executing the coroutine task, the scheduler of the task scheduling framework only needs to execute the pending functions encapsulated in the coroutine task.

[0081] For the task scheduling framework, the tasks to be executed are usually in the task queue, and the electronic device obtains the queued coroutine tasks from the task queue through the scheduler of the task scheduling framework for execution.

[0082] Among them, asynchronous functions can also be written in other languages ​​with stackless coroutines, such as C++ / python.

[0083] 302: Construct the Waker of the asynchronous function according to the task handle of the coroutine task.

[0084] In an embodiment of the present application, the electronic device needs to call the poll method of the asynchronous function through the underlying task scheduling framework, but the poll method requires the Waker associated with the asynchronous function as a parameter. Therefore, before calling the poll method of the asynchronous function, it is necessary to first build the Waker associated with the asynchronous function.

[0085] Exemplarily, the electronic device can obtain the task scheduling function of the task scheduling framework based on the construction logic of the Waker, and obtain the task handle of the underlying coroutine task, and use the task scheduling function of the task scheduling framework and the task handle of the coroutine task as parameters to construct a Waker associated with the asynchronous function. Specifically, the task scheduling function and the task handle are used as the input parameters of the Waker, and the data pointer in the Waker points to the task handle, so that the underlying coroutine task is adapted to the upper Waker. Exemplarily, the task scheduling function of the task scheduling framework can be set as a wake function.

[0086] In this implementation, the task scheduling function of the underlying task scheduling framework and the task handle of the coroutine task on the task scheduling framework side are used as the input parameters of the Waker, and a Waker associated with the asynchronous function is constructed, thereby realizing the adaptation of the underlying task scheduling framework and the Waker on the Rust side. When the electronic device calls the wake function in the Waker, the underlying task scheduling framework can re-execute the suspended task.

[0087] For example, the underlying task scheduling framework usually uses thread local storage (Thread Local Storage) to save the tasks executed by the current working thread. Therefore, when executing a coroutine task, we can obtain the coroutine task by accessing the Thread Local Storage, and use its task handle (or task pointer) and the task scheduling function of the task scheduling framework as parameters to build this Waker.

[0088] For example, Figure 4 As shown, the task scheduling framework can encapsulate the asynchronous function submitted by the user into a task structure, and at the same time create a Waker bound to the Task, and the data pointer in the Waker points to the Task associated with it.

[0089] 303: According to Waker, call the poll method of the asynchronous function to poll the coroutine task and process the return result of the poll method.

[0090] In an embodiment of the present application, after constructing a Waker associated with an asynchronous function based on the construction logic of the Waker, the Waker is used as a parameter of the poll method of the asynchronous function and passed into the poll method, and then the poll method of the asynchronous function can be called. Based on the execution logic of the poll method, the electronic device calls the poll method of the asynchronous function through the scheduler of the task scheduling framework to poll the coroutine task to promote the execution of the coroutine task. The return result of the poll method includes: Pending or Ready (result), wherein Pending indicates that the coroutine task is blocked, and Ready (result) indicates that the coroutine task is executed. Based on the processing logic of the return result of the poll method, the electronic device performs corresponding processing on the return result of the poll method through the scheduler of the task scheduling framework.

[0091] If the return result of the poll method indicates that the coroutine task is blocked, the coroutine task is suspended, removed from the task queue, and the event that the coroutine task can be executed again is waited for, and the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to blocked. Since the coroutine task is a stackless coroutine, its essence is a state machine. Therefore, after the coroutine task is blocked, its state needs to be converted. If the return result of the poll method indicates that the coroutine task is executed, the task state conversion interface is called to set the state of the coroutine task to completed.

[0092] In this implementation, the electronic device schedules the poll method of the asynchronous function through the underlying scheduler to promote the execution of the coroutine task, and when the return result indicates that the coroutine task is blocked, the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to blocked, and when the return result indicates that the coroutine task is completed, the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to completed, so that the underlying task scheduling framework can perceive the state of the coroutine task. For the Rust side, the coroutine task is an asynchronous function, so based on the return result of the poll method, the Rust side can also obtain the execution status of the asynchronous function.

[0093] Exemplarily, when the return result of the poll method indicates that the coroutine task is blocked, the method further includes:

[0094] Call the task acquisition interface of the task scheduling framework to obtain the wakeup device;

[0095] When it is detected that the coroutine task is ready to be re-executed, the task wake-up interface of the task scheduling framework is called to wake up the coroutine task through the wake function of Waker.

[0096] In the embodiment of the present application, exemplarily, when the coroutine task encounters a blockage, the electronic device saves the Waker associated with the asynchronous function somewhere, and enables another thread to listen to the coroutine task. When the coroutine task is ready to be re-executed, that is, the listening event arrives, the electronic device calls the task acquisition interface of the task scheduling framework to obtain the Waker from the place where the Waker is saved, and calls the task wake-up interface of the task scheduling framework to use the wake function to wake up the coroutine task, and puts the coroutine task back into the task queue.

[0097] Exemplarily, the input parameter "cx" of the poll method includes the Waker of the asynchronous function. When the coroutine task encounters a block, the poll method can return the Waker in the input parameter "cx" to the task acquisition interface of the task scheduling framework, that is, the Waker does not need to be saved somewhere, but can be directly returned to the task acquisition interface. In other words, the task acquisition interface of the task scheduling framework obtains the Waker of the asynchronous function from the input parameter of the poll method.

[0098] For example, please see Figure 4 The electronic device calls the task wake-up interface through the scheduler of the task scheduling framework to re-add the Task to the task queue, and calls the poll method of the asynchronous function to poll the coroutine task again to start executing the coroutine task from the place where it was suspended last time.

[0099] For example, Figure 5 As shown, after the Future of the above Generator is submitted as an asynchronous task, its poll method will be called at the bottom layer to advance the execution of the task. If the Boolean value of the structure is false, the Boolean value is changed to true and Pending is returned. The electronic device can wake it up through the task wake-up interface at the bottom layer, and call the poll method to poll again after waking up. If the Boolean value of the structure is true, Ready is returned.

[0100] In this implementation, although the logic of the Waker mechanism is implemented on the Rust side, the task wakeup operation is actually performed through the task acquisition interface and task wakeup interface of the task scheduling framework, that is, task wakeup is implemented in the underlying task scheduling framework.

[0101] Exemplarily, the asynchronous function created by the user will generate a corresponding asynchronous task on the Rust side, and the Rust side will return the task handle of the asynchronous function. The user can perform the ".await" operation on the task handle, which means that calling the asynchronous function requires waiting for the asynchronous function to be executed. The function that calls the asynchronous function is defined as the target asynchronous function. For example, "mission1" is an asynchronous function that implements the ".await" operation, and "func" will call "mission1" when executed, so "func" is the target asynchronous function. It can also be understood that the target asynchronous function is the parent function, the corresponding task is the parent task, the asynchronous function is the child function, and the corresponding task is the child task. In the task scheduling framework, when the await operation of the task handle of the asynchronous function in Rust is executed, the target scheduling function will confirm whether the asynchronous function has been executed. If the asynchronous function has not been executed, the target asynchronous function will pass its own Waker down to the asynchronous function.

[0102] For example, when the coroutine task is executed, the task scheduling framework will also return the return result of the poll method (for example: Ready(result)) to the task handle of the asynchronous function in Rust, and call the task wake-up interface to use the target asynchronous function to pass the Waker of the asynchronous function to wake up the target asynchronous function. That is, after the subtask is executed, the parent task needs to be woken up by the Waker of the parent task.

[0103] In this implementation, the electronic device returns the return result of the poll method in the task scheduling framework to the task handle of the asynchronous function in Rust, so that the target asynchronous function that calls the asynchronous function perceives that the asynchronous function has been executed. Then the task wakeup interface of the task scheduling framework is called to use the Waker passed to the asynchronous function by the target asynchronous function to wake up the target asynchronous function to avoid the target function being blocked.

[0104] It can be seen that in the embodiment of the present application, the electronic device encapsulates the asynchronous function on the Rust side as a coroutine task and gives it to the underlying task scheduling framework. When the poll method of the asynchronous function needs to be called at the bottom to poll the coroutine task, the Waker of the asynchronous function is constructed according to the task handle of the coroutine task in the task scheduling framework, so as to adapt the upper-level task wake-up logic to the task scheduling framework, so that the underlying task scheduling framework can call the upper-level method to promote the execution of the coroutine task. In this way, the Rust asynchronous primitive is adapted to the underlying task scheduling framework of other languages, and the upper-level asynchronous function can be passed as a task to the task scheduling framework for execution, so that various services in different languages ​​can share the same task scheduling framework, realize the unified management of thread resources, and then reduce the waste of thread resources. In addition, although the underlying task scheduling framework reuses the capabilities of the Rust asynchronous primitive, the upper-level logic implementation still adopts the Rust language, which is conducive to ensuring the security of the business.

[0105] See also Figure 6 , Figure 6 A flowchart of another cross-language task processing method provided in an embodiment of the present application.

[0106] like Figure 6 As shown, the method includes steps 601-605:

[0107] 601: Obtain the coroutine task to be executed by the underlying task scheduling framework; the coroutine task includes an asynchronous function, and the task scheduling framework and the asynchronous function are written in different programming languages;

[0108] 602: Obtain the task scheduling function of the task scheduling framework;

[0109] 603: Get the task handle of the coroutine task;

[0110] 604: Construct Waker using the task handle of the coroutine task and the task scheduling function of the task scheduling framework as parameters;

[0111] 605: According to Waker, call the poll method of the asynchronous function to poll the coroutine task and process the return result of the poll method.

[0112] Exemplarily, before step 601, the method further includes:

[0113] Get the asynchronous function submitted by the user through the interface provided by Rust;

[0114] Call the business logic submission interface of the task scheduling framework to obtain the business logic of the asynchronous function; the business logic includes the construction logic of the wakeup device, the execution logic of the polling method, and the processing logic of the return result of the polling method;

[0115] Encapsulate the construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method into a function to be processed;

[0116] The function to be processed is encapsulated as a task structure of the task scheduling framework to obtain a coroutine task.

[0117] Exemplarily, processing the return result of the poll method includes:

[0118] If the return result of the poll method indicates that the coroutine task is blocked, the coroutine task is suspended and the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to blocked;

[0119] If the return result of the poll method indicates that the coroutine task is completed, the task state conversion interface is called to set the state of the coroutine task to completed.

[0120] Exemplarily, when the return result of the poll method indicates that the coroutine task is blocked, the method further includes:

[0121] Call the task acquisition interface of the task scheduling framework to obtain Waker;

[0122] When it is detected that the coroutine task is ready to be re-executed, the task wake-up interface of the task scheduling framework is called to wake up the coroutine task through the wake function of Waker.

[0123] Exemplarily, the asynchronous function in Rust is a function called by the target asynchronous function, and the task handle of the asynchronous function in Rust implements the await operation;

[0124] When the return result of the poll method indicates that the coroutine task is completed, the method further includes:

[0125] Return the result of the poll method to the asynchronous function's task handle in Rust; and,

[0126] Calling the task wakeup interface uses the Waker of the target asynchronous function to wake up the target asynchronous function; the Waker of the target asynchronous function is passed to the asynchronous function when executing the await operation of the task handle of the asynchronous function in Rust.

[0127] Exemplarily, calling the task acquisition interface of the task scheduling framework to obtain the wakeup device includes:

[0128] Call the task acquisition interface of the task scheduling framework to obtain the wakeup device from the input parameters of the polling method.

[0129] in, Figure 6 The implementation of each step in the embodiment shown is Figure 3-Figure 5The embodiments shown have been described above and can achieve the same or similar beneficial effects.

[0130] To facilitate a better understanding of the solution provided by this application, a brief description is given below using a Future.

[0131] See also Figure 7 , Figure 7 The overall flow chart of a cross-language task processing method provided in the embodiment of the present application is as follows. Figure 7 As shown, the user submits Future through the interface provided by Rust, and the Future is encapsulated as a coroutine task and passed to the underlying task scheduling framework. When the scheduler of the task scheduling framework executes the coroutine task, it obtains the coroutine task from the task queue and obtains the task handle of the coroutine task. According to the task handle, the Waker of Future is constructed, and the Waker is passed as a parameter to the poll method of Future, which means that the poll method can be called. The scheduler of the task scheduling framework calls the poll method of Future to poll the coroutine task. If the poll method returns Pending, the task state is set to blocked. If the poll method returns Ready, the task state is set to complete, and the result is returned to the task handle of Future on the Rust side to wake up the parent task that calls the Future. When it is detected that the coroutine task can be re-executed, the Waker of Future is used to wake up the coroutine task and re-add it to the task queue for execution until the coroutine task is executed. It is not difficult to see that in the embodiment of the present application, since the Rust asynchronous primitive is adapted to the underlying task scheduling framework of other languages, the execution of the task can actually be completed in the underlying task scheduling framework.

[0132] The method of the embodiment of the present application is described above, and the device of the embodiment of the present application is provided below.

[0133] See also Figure 8 , Figure 8 This is a schematic diagram of the structure of a cross-language task processing device provided in an embodiment of the present application. Figure 8 As shown, the device includes an acquisition unit 801 and a processing unit 802; wherein:

[0134] An acquisition unit 801 is used to acquire a coroutine task to be executed by an underlying task scheduling framework; the coroutine task includes an asynchronous function, and the task scheduling framework and the asynchronous function are written in different programming languages;

[0135] The processing unit 802 is used to construct a wakeup device of the asynchronous function according to the task handle of the coroutine task; according to the wakeup device, the polling method of the asynchronous function is called to poll the coroutine task and process the return result of the polling method.

[0136] It can be seen that in Figure 8 In the device shown, the asynchronous function on the Rust side is encapsulated as a coroutine task and given to the underlying task scheduling framework. When the bottom layer needs to call the polling method of the asynchronous function to poll the coroutine task, the asynchronous function wakeup device is constructed according to the task handle of the coroutine task in the task scheduling framework to adapt the upper-layer task wakeup logic to the task scheduling framework, so that the underlying task scheduling framework can call the upper-layer method to promote the execution of the coroutine task. In this way, the Rust asynchronous primitive is adapted to the underlying task scheduling framework of other languages, and the upper-layer asynchronous functions can be passed as a task to the task scheduling framework for execution, so that various services in different languages ​​can share the same task scheduling framework, realize the unified management of thread resources, and thus reduce the waste of thread resources.

[0137] In a possible implementation, the acquiring unit 801 is further configured to:

[0138] Get the task scheduling function of the task scheduling framework;

[0139] In terms of constructing a wakeup device for an asynchronous function according to a task handle of a coroutine task, the processing unit 802 is specifically used for:

[0140] The task handle of the coroutine task and the task scheduling function of the task scheduling framework are used as parameters to build the wakeup device.

[0141] In one possible implementation, the asynchronous function is written in Rust;

[0142] The acquisition unit 801 is further used to acquire the asynchronous function submitted by the user through the interface provided by Rust;

[0143] The processing unit 802 is also used to call the business logic submission interface of the task scheduling framework to obtain the business logic of the asynchronous function; the business logic includes the construction logic of the wakeup device, the execution logic of the polling method and the processing logic of the return result of the polling method; the construction logic of the wakeup device, the execution logic of the polling method and the processing logic of the return result of the polling method are encapsulated as a function to be processed; the function to be processed is encapsulated as a task structure of the task scheduling framework to obtain a coroutine task.

[0144] In a possible implementation, in terms of processing the return result of the polling method, the processing unit 802 is specifically configured to:

[0145] If the return result of the polling method indicates that the coroutine task is blocked, the coroutine task is suspended, and the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to blocked;

[0146] If the return result of the polling method indicates that the coroutine task is completed, the task state conversion interface is called to set the state of the coroutine task to completed.

[0147] In a possible implementation, when the return result of the polling method indicates that the coroutine task is blocked, the processing unit 802 is further configured to:

[0148] Call the task acquisition interface of the task scheduling framework to obtain the wakeup device;

[0149] When it is detected that the coroutine task is ready to be re-executed, the task wake-up interface of the task scheduling framework is called to wake up the coroutine task through the wake-up function of the waker.

[0150] In a possible implementation, the asynchronous function in Rust is a function called by the target asynchronous function, and the task handle of the asynchronous function in Rust implements the await operation;

[0151] When the return result of the polling method indicates that the coroutine task is executed, the processing unit 802 is further configured to:

[0152] Return the result of the polling method to the asynchronous function's Rust task handle; and,

[0153] Calling the task wakeup interface uses the wakeup function of the target asynchronous function to wake up the target asynchronous function; the wakeup function of the target asynchronous function is passed to the asynchronous function when executing the await operation of the task handle of the asynchronous function in Rust.

[0154] In a possible implementation, in calling the task acquisition interface of the task scheduling framework to obtain the wakeup device, the processing unit is specifically used to:

[0155] Call the task acquisition interface of the task scheduling framework to obtain the wakeup device of the asynchronous function from the input parameters of the polling method.

[0156] Based on the description of the above method embodiment and device embodiment, the present application embodiment also provides an electronic device. Fig. 9 , Fig. 9A schematic diagram of the structure of an electronic device provided in an embodiment of the present application, the electronic device at least includes a processor 901, a memory 902, an input device 903 and an output device 904, and one or more programs, one or more programs are stored in the memory 902, and the various parts are interconnected through a bus or other means, wherein the input device 903 and the output device 904 can be the same device, the input device 903 can be used to receive user input (such as: trigger event), and the output device 904 can be used to output the interface rendered by the electronic device. Among them, the input device 903 can be a keyboard, a touch screen, a radio frequency receiver, etc.; the output device 904 can be a speaker, a display, a radio frequency transmitter, etc. Figure 8 Each unit shown may be implemented by the processor 901 , memory 902 , input device 903 , and output device 904 described above.

[0157] The memory 902 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or portable read-only memory (CD-ROM), and is used to store relevant computer programs and data.

[0158] The processor 901 may be one or more central processing units (CPUs). When the processor 901 is a CPU, the CPU may be a single-core CPU or a multi-core CPU.

[0159] The processor 901 in the electronic device is used to read one or more programs stored in the memory 902 and perform the following operations:

[0160] Get the coroutine tasks to be executed by the underlying task scheduling framework; the coroutine tasks include asynchronous functions, and the task scheduling framework and the asynchronous functions are written in different programming languages;

[0161] Build the asynchronous function wakeup handler based on the coroutine task's task handle;

[0162] According to the wakeup device, the polling method of the asynchronous function is called to poll the coroutine task and process the return result of the polling method.

[0163] It can be seen that in Fig. 9In the electronic device shown, the asynchronous function on the Rust side is encapsulated as a coroutine task and given to the underlying task scheduling framework. When the polling method of the asynchronous function needs to be called at the bottom layer to poll the coroutine task, the awakener of the asynchronous function is constructed according to the task handle of the coroutine task in the task scheduling framework, so as to adapt the upper-layer task wake-up logic to the task scheduling framework, so that the underlying task scheduling framework can call the upper-layer method to advance the execution of the coroutine task. In this way, the Rust asynchronous primitive is adapted to the underlying task scheduling framework of other languages, and the upper-layer asynchronous functions can be passed as a task to the task scheduling framework for execution, so that various services in different languages ​​can share the same task scheduling framework, realize the unified management of thread resources, and thus reduce the waste of thread resources.

[0164] It should be noted that the implementation of each operation can also refer to Figure 3 or Figure 6 The corresponding description of the method of any one of the embodiments shown.

[0165] It should be noted that although Fig. 9 The electronic device shown only shows a processor 901, a memory 902, an input device 903, and an output device 904. However, in the specific implementation process, those skilled in the art should understand that the electronic device also includes other devices necessary for normal operation, such as: memory, power supply, application client module, etc. At the same time, according to specific needs, those skilled in the art should understand that the electronic device may also include hardware devices for implementing other additional functions. In addition, those skilled in the art should understand that the electronic device may also include only the devices necessary to implement the embodiments of the present application, and does not necessarily include Fig. 9 All devices shown in .

[0166] The present application also provides a chip, including: a processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes the above-mentioned Figure 3 or Figure 6 The method according to any one of the embodiments. The chip may be a chip in an electronic device.

[0167] The present application also provides a computer-readable storage medium (Memory), which stores a computer program. When the computer program is executed, the above-mentioned Figure 3 or Figure 6The method described in any one of the embodiments. It can be understood that the computer-readable storage medium here can include both the built-in storage medium in the device and the extended storage medium supported by the device. The computer-readable storage medium provides a storage space, which stores the operating system of the device. In addition, one or more computer programs suitable for being loaded and executed by the processor of the device are also stored in the storage space. It should be noted that the computer-readable storage medium here can be a high-speed RAM or a non-volatile memory, such as at least one disk storage; optionally, it can also be at least one computer-readable storage medium located away from the aforementioned processor.

[0168] The present application also provides a computer program product, which includes: a computer program code. When the computer program code is executed by an electronic device, Figure 3 or Figure 6 The method process described in any one of the embodiments is implemented.

[0169] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0170] It should be understood that the processor mentioned in the embodiments of the present application may be a CPU, or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0171] It should also be understood that the memory mentioned in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a ROM, a programmable read-only memory (Programmable ROM, PROM), an EPROM, an electrically erasable programmable read-only memory (ElectricallyEPROM, EEPROM) or a flash memory. The volatile memory may be a RAM, which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (Static RAM, SRAM), dynamic random access memory (Dynamic RAM, DRAM), synchronous dynamic random access memory (Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (Synchlink DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DRRAM).

[0172] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, the memory (storage module) is integrated in the processor.

[0173] It should be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0174] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0175] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely exemplary. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0176] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0177] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. If the above integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable storage medium.

[0178] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0179] The steps in the method of the embodiment of the present application can be adjusted in order, combined and deleted according to actual needs.

[0180] The modules in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.

[0181] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A cross-language task processing method, characterized in that: The method comprises: Obtaining a coroutine task to be executed by an underlying task scheduling framework; the coroutine task includes an asynchronous function, and the task scheduling framework and the asynchronous function are written in different programming languages; Constructing a wakeup device for the asynchronous function according to the task handle of the coroutine task; According to the wakeup device, the polling method of the asynchronous function is called to poll the coroutine task and process the return result of the polling method.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining the task scheduling function of the task scheduling framework; The step of constructing the asynchronous function wakeup device according to the task handle of the coroutine task includes: The wakeup device is constructed by taking the task handle of the coroutine task and the task scheduling function of the task scheduling framework as parameters.

3. The method according to claim 1 or 2, characterized in that: The asynchronous function is written in Rust language; before obtaining the coroutine task to be executed by the underlying task scheduling framework, the method further includes: Obtain the asynchronous function submitted by the user through the interface provided by Rust; Calling the business logic submission interface of the task scheduling framework to obtain the business logic of the asynchronous function; the business logic includes the construction logic of the wakeup device, the execution logic of the polling method and the processing logic of the return result of the polling method; Encapsulate the construction logic of the wake-up device, the execution logic of the polling method, and the processing logic of the return result of the polling method into a function to be processed; The function to be processed is encapsulated as a task structure of the task scheduling framework to obtain the coroutine task.

4. The method according to any one of claims 1 to 3, characterized in that: The processing of the return result of the polling method includes: If the return result of the polling method indicates that the coroutine task is blocked, the coroutine task is suspended, and the task state conversion interface of the task scheduling framework is called to set the state of the coroutine task to blocked; If the return result of the polling method indicates that the coroutine task is executed, the task state conversion interface is called to set the state of the coroutine task to completed.

5. The method according to claim 4, characterized in that In the case where the return result of the polling method indicates that the coroutine task is blocked, the method further includes: Calling the task acquisition interface of the task scheduling framework to obtain the wakeup device; When it is monitored that the coroutine task is ready to be re-executed, the task wake-up interface of the task scheduling framework is called to wake up the coroutine task through the wake-up function of the waker.

6. The method according to claim 5, characterized in that The asynchronous function is a function called by the target asynchronous function in Rust, and the task handle of the asynchronous function in Rust implements the await operation; In the case where the return result of the polling method indicates that the coroutine task is executed, the method further includes: Return the return result of the polling method to the task handle of the asynchronous function in Rust; as well as, The task wake-up interface is called to use the wake-up device of the target asynchronous function to wake up the target asynchronous function; the wake-up device of the target asynchronous function is passed to the asynchronous function when executing the await operation of the task handle of the asynchronous function in Rust.

7. The method according to claim 5, characterized in that The calling of the task acquisition interface of the task scheduling framework to acquire the wake-up device includes: The task acquisition interface of the task scheduling framework is called to obtain the wakeup device from the input parameters of the polling method.

8. An electronic device, characterized in that: The system comprises a processor, a memory, and one or more programs, wherein the processor is connected to the memory, the one or more programs are stored in the memory, and are configured to implement the method according to any one of claims 1 to 7 when executed by the processor.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program for execution by a device, and when the computer program is executed, the method according to any one of claims 1 to 7 is implemented.

10. A computer program product, characterized in that When the computer program product is executed by an electronic device, the electronic device executes the method as claimed in any one of claims 1 to 7.

Images