Task processing method, device and equipment and readable storage medium

Abstract

The invention provides a task processing method, device and equipment and a readable storage medium, a task function is used as an instruction to be transmitted in different runtime environments, the task function is packaged in an intermediate code form irrelevant to a hardware architecture and a memory address, and configuration information and an access control strategy required by execution are combined, so that the task processing efficiency is improved. The method comprises the following steps: establishing a complete instruction packet which can be independently transmitted and executed, and mapping an intermediate code corresponding to a task function to a local executable memory of an instruction executor, so that the instruction executor runs the task function in the local memory of a system, and a provider and the executor do not need to pre-agree a data structure or share an interface type definition; and safe and dynamic task execution without strong coupling agreement is realized in a runtime environment in which an instruction provider and an executor are completely isolated.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a task processing method, apparatus, device and readable storage medium. Background Technology

[0002] In traditional operating systems and distributed systems, inter-process communication primarily relies on shared memory, message queues, and remote procedure calls (RPCs). However, traditional message queues require both communicating parties to strictly agree on the data format of messages. If either party changes the protocol structure, the other party must synchronously update its logic to avoid deserialization failures or runtime exceptions. RPCs rely on interface definition languages ​​to describe service contracts, requiring clients and servers to complete interface binding at compile time. After an interface change, all callers must recompile and republish. Clearly, existing communication methods have a strong dependency on predefined data formats, communication protocols, or interface definitions, making it difficult to support independent upgrades and dynamic expansion, resulting in high maintenance costs and hindering rapid system iteration and high availability. Summary of the Invention

[0003] In view of this, in order to solve the above-mentioned technical problems, this application provides a task processing method, apparatus, device and readable storage medium.

[0004] Specifically, this application is implemented through the following technical solution: According to a first aspect of the embodiments of this application, a task processing method is provided, the method comprising: The instruction provider compiles the source code of the task function to be executed into intermediate code, which is independent of hardware architecture and memory address; The instruction provider determines the configuration information required for the execution of the task function and obtains the access control policy when the task function is executed. Based on the intermediate code, the configuration information, and the access control policy, the instruction provider constructs an instruction package and sends the instruction package to the instruction executor. The instruction provider and the instruction executor run in different runtime environments that are isolated from each other. After receiving the instruction packet, the instruction executor maps the machine code to a readable and executable memory region in its local memory based on the configuration information, and executes the machine code in the memory region based on the configuration information and the access control policy to execute the task function, and returns the execution result of the task function to the instruction provider.

[0005] Optionally, the instruction packet is sent to the instruction executor, including: When the instruction executor and the instruction provider are different processes of the same device, the instruction packet is transmitted to the instruction executor through a local inter-process communication channel. When the instruction executor and the instruction provider are different devices, the instruction packet is transmitted to the instruction executor via a Socket network connection between the instruction executor and the instruction provider.

[0006] Optionally, the source code of the task function to be executed is compiled into intermediate code, including: Based on the compilation tags of the task function source code, determine the compilation method of the task function source code; The source code of the task function is compiled using the aforementioned compilation method to generate an intermediate representation that is independent of the hardware architecture; The intermediate representation is converted into binary data format and encapsulated into intermediate code containing an execution entry point identifier.

[0007] Optionally, based on the configuration information, the machine code is mapped to a readable and executable memory region in the local memory of the instruction executor, including: Based on the code memory requirement information in the configuration information, a memory region is requested from the operating system of the instruction executor, and the access permissions of the memory region are set to be readable and executable; The intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor, and the machine code is written into the memory area.

[0008] Optionally, executing the machine code in the memory region to execute the task function based on the configuration information and the access control policy includes: Based on the function execution entry information in the configuration information, determine the entry address of the described function in the memory region; The entry address is converted into a function pointer, and the function pointer is called to start the execution of the task function; During the execution of the task function, the access control policy is used to monitor the running behavior of the task function in real time, and the execution of the task function is terminated when abnormal access behavior is detected.

[0009] Optionally, the instruction packet is sent to the instruction executor, including: When the task function corresponds to multiple executable candidate executors, based on the running status information of each candidate executor and at least one setting information, a candidate executor is selected from the multiple candidate executors as the instruction executor, and the instruction package is sent to the instruction executor; The configuration information includes at least a preset load balancing strategy and a network topology-based nearest routing strategy; the multiple candidate executors represent different processes on the same device or multiple candidate executors represent multiple different devices interconnected in the network.

[0010] Optionally, the intermediate code corresponding to the machine code has a unique function identifier; the instruction executor retains the memory region for machine code that has been mapped to the memory region within a preset time window, and releases the memory region when the preset time window expires; Constructing an instruction package based on the intermediate code, the configuration information, and the access control policy includes: obtaining a unique function identifier for the intermediate code; if there is no sending record of sending the intermediate code corresponding to the function identifier to the designated executor within the preset time window before the current time, then encapsulating the function identifier, the intermediate code, the configuration information, and the access control policy to generate the instruction package; otherwise, encapsulating the function identifier, the configuration information, and the access control policy to generate the instruction package; the instruction package does not contain the intermediate code.

[0011] Optionally, after receiving the instruction packet, the method further includes: Check whether there is a target memory region that matches the function identifier in the instruction package in each memory region locally reserved by the instruction executor; If it exists, the machine code is executed directly in the target memory region based on the configuration information and the access control policy to execute the task function; If it does not exist, then if the instruction package includes intermediate code, the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor; otherwise, an indication message indicating that the function identifier was not matched is returned to the instruction sender to request the sending of the intermediate code corresponding to the function identifier in the instruction package.

[0012] Optionally, sending the instruction package to the instruction executor includes: aggregating the instruction packages encapsulated by multiple task functions to be executed into a batch transmission unit, and sending the batch transmission unit to the instruction executor through a single communication connection; After receiving the batch transmission unit, the instruction executor compiles each intermediate code contained in the batch transmission unit locally, maps the compiled machine code to a readable and executable memory area allocated for the machine code, and establishes an association between the function identifier of each intermediate code and the memory area mapped to the corresponding machine code, so as to call and execute from multiple memory areas based on the function identifier in the instruction packet subsequently sent by the instruction executor.

[0013] Optionally, before constructing the instruction package, the method further includes: obtaining an access token for the task function to be executed from an authentication center, and encapsulating the access token together with the instruction package; the access token includes a token validity period and an audience field; the field value of the audience field points to a set of executor identifiers that can call the task function to be executed; After receiving the instruction packet, the method further includes: verifying whether the access token in the instruction packet is within its validity period, and verifying whether the self-identifier of the instruction executor is within the range of field values ​​of the audience field; if both verifications pass, compiling the intermediate code in the instruction packet locally into machine code supported by the instruction executor.

[0014] According to a second aspect of the embodiments of this application, a task processing apparatus is provided, the apparatus comprising: The task sending module is configured to: compile the source code of the task function to be executed into intermediate code, which is independent of hardware architecture and memory address; determine the configuration information required for the execution of the task function and obtain the access control policy when the task function is executed; construct an instruction package based on the intermediate code, the configuration information and the access control policy, and send the instruction package to the instruction executor; wherein the instruction provider and the instruction executor run in different runtime environments that are isolated from each other. The task execution module is configured such that, after receiving the instruction packet, the instruction executor maps the machine code to a readable and executable memory region in the instruction executor's local memory based on the configuration information, executes the machine code in the memory region based on the configuration information and the access control policy to execute the task function, and returns the execution result of the task function to the instruction provider.

[0015] Optionally, when the task sending module is configured to send the instruction packet to the instruction executor, it includes: When the instruction executor and the instruction provider are different processes on the same device, the instruction packet is transmitted to the instruction executor through a local inter-process communication channel; when the instruction executor and the instruction provider are on different devices, the instruction packet is transmitted to the instruction executor through a Socket network connection between the instruction executor and the instruction provider.

[0016] Optionally, when the task sending module is configured to compile the source code of the task function to be executed into intermediate code, it includes: Based on the compilation tags of the task function source code, the compilation method of the task function source code is determined; the task function source code is compiled using the compilation method to generate an intermediate representation independent of hardware architecture; the intermediate representation is converted into binary data format and encapsulated into intermediate code containing an execution entry point identifier.

[0017] Optionally, when the task execution module is configured to map the machine code to a readable and executable memory region in the local memory of the instruction executor based on the configuration information, it includes: Based on the code memory requirement information in the configuration information, a memory region is requested from the operating system of the instruction executor, and the access permissions of the memory region are set to be readable and executable; the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor, and the machine code is written into the memory region.

[0018] Optionally, when the task execution module is configured to execute the machine code in the memory region based on the configuration information and the access control policy to execute the task function, it includes: Based on the function execution entry information in the configuration information, the entry address of the task function in the memory region is determined; the entry address is converted into a function pointer, and the function pointer is called to start the execution of the task function; during the execution of the task function, the running behavior of the task function is monitored in real time through the access control policy, and the execution of the task function is terminated when abnormal access behavior is detected.

[0019] Optionally, when the task sending module is configured to send the instruction packet to the instruction executor, it includes: When the task function corresponds to multiple executable candidate executors, based on the running status information of each candidate executor and at least one setting information, a candidate executor is selected from the multiple candidate executors as the instruction executor, and the instruction packet is sent to the instruction executor; wherein, the setting information includes at least a preset load balancing strategy and a proximity routing strategy based on network topology; the multiple candidate executors represent different processes in the same device, or the multiple candidate executors represent multiple different devices interconnected in the network.

[0020] Optionally, the intermediate code corresponding to the machine code has a unique function identifier; the instruction executor retains the memory region for machine code that has been mapped to the memory region within a preset time window, and releases the memory region when the preset time window expires; When the task sending module is configured to construct an instruction package based on the intermediate code, the configuration information, and the access control policy, the following steps are included: obtaining a unique function identifier for the intermediate code; if there is no sending record of sending the intermediate code corresponding to the function identifier to the designated executor within the preset time window before the current time, then encapsulating the function identifier, the intermediate code, the configuration information, and the access control policy to generate the instruction package; otherwise, encapsulating the function identifier, the configuration information, and the access control policy to generate the instruction package; the instruction package does not contain the intermediate code.

[0021] Optionally, after receiving the instruction packet, the task execution module further includes: Check whether there is a target memory region that matches the function identifier in the instruction package in each memory region locally reserved by the instruction executor; If it exists, the machine code is executed directly in the target memory region based on the configuration information and the access control policy to execute the task function; If it does not exist, then if the instruction package includes intermediate code, the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor; otherwise, an indication message indicating that the function identifier was not matched is returned to the instruction sender to request the sending of the intermediate code corresponding to the function identifier in the instruction package.

[0022] Optionally, when the task sending module is configured to send the instruction package to the instruction executor, it includes: aggregating the instruction packages encapsulated by multiple task functions to be executed into a batch transmission unit, and sending the batch transmission unit to the instruction executor through a single communication connection; The task execution module is configured such that after receiving the batch transmission unit, the instruction executor performs local compilation of each intermediate code contained in the batch transmission unit, maps the compiled machine code to a readable and executable memory area allocated for the machine code, and establishes an association between the function identifier of each intermediate code and the memory area mapped to the corresponding machine code, so as to call and execute from multiple memory areas based on the function identifier in the instruction packet subsequently sent by the instruction executor.

[0023] Optionally, before constructing the instruction package, the task sending module further includes: obtaining an access token for the task function to be executed from the authentication center, and encapsulating the access token together with the instruction package; the access token includes a token validity period and an audience field; the field value of the audience field points to a set of executor identifiers that can call the task function to be executed; After receiving the instruction packet, the task execution module further includes: verifying whether the access token in the instruction packet is within its validity period, and verifying whether the self-identifier of the instruction executor is within the range of field values ​​of the audience field; if both verifications pass, the intermediate code in the instruction packet is locally compiled into machine code supported by the instruction executor.

[0024] According to a third aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a memory and a processor; the memory being used to store a computer program; the processor being used to execute the above-described task processing method by invoking the computer program.

[0025] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the program, when executed by a processor, implements the above-described task processing method.

[0026] The technical solutions provided in this application embodiment may include the following beneficial effects: In the technical solution provided in this application, the task function itself is transmitted as a complete instruction in different runtime environments. The task function is mapped to the executable memory of the instruction executor in the form of an instruction, so that the instruction executor runs the task function in the local memory of the system. This breaks through the dependence of the traditional remote call mechanism on fixed interface definition and preset communication protocol. There is no need for the provider and the executor to pre-agree on data structure or shared interface type definition. The task logic is encapsulated and issued on demand by the instruction provider rather than pre-deployed by the instruction executor. By encapsulating the task function in the form of intermediate code that is independent of hardware architecture and memory address, and combining it with the configuration information and access control policies required for execution, a complete instruction package that can be independently transmitted and executed is constructed. Secure, dynamic, and non-coupling-free task execution is achieved in a runtime environment where the instruction provider and the executor are completely isolated.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Furthermore, no embodiment in this application needs to achieve all the effects described above. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0029] Figure 1A This is an architectural flowchart illustrating a task processing method according to an exemplary embodiment of this application; Figure 1BThis is a schematic diagram illustrating the steps of a task processing method according to an exemplary embodiment of this application; Figure 2 This is a schematic diagram illustrating a communication method in which an instruction provider sends an instruction packet to an instruction execution method, as shown in an exemplary embodiment of this application. Figure 3 This is a schematic diagram illustrating an exemplary embodiment of the present application of running the intermediate code in a readable and executable memory region to execute a task function; Figure 4 This is a schematic diagram of the structure of a task processing device shown in an exemplary embodiment of this application; Figure 5 This is a hardware schematic diagram of an electronic device illustrated in an exemplary embodiment of this application. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another.

[0031] In traditional operating systems and distributed systems, inter-process communication mainly relies on mechanisms such as shared memory, message queues, and RPC (Remote Procedure Call). However, these communication methods have strong coupling and runtime constraints, making it difficult to meet the current application requirements for high availability, rapid iteration, and flexible expansion.

[0032] For example, traditional message queues require both communicating parties to strictly agree on the data format of messages. When either party changes the protocol structure, the other party must synchronously update its logic. Messages sent by the producer must be in a format that the consumer can understand; otherwise, messages will be unrecognizable or processed incorrectly. For instance, in a financial transaction system, any addition or removal of a transaction message field requires all participating nodes to upgrade collaboratively. When a transaction message is upgraded from {"amount": 100} to {"amount": 100,"currency": "USD"}, older consumers may crash because they cannot parse the new fields, easily leading to version inconsistencies, significantly increasing system maintenance costs and affecting stability. Similarly, RPC frameworks (such as gRPC) rely on Interface Definition Language (IDL) to describe service contracts. Clients and servers must share the same interface files and complete the binding at compile time. When the interface file changes, the client must be recompiled and republished along with the server upgrade. Difficulties in updating mobile or embedded devices will affect business continuity. Taking an e-commerce system as an example, when the product query interface is upgraded from GetProduct(id) to GetProduct(id, region), the old version of the App cannot obtain data due to the lack of the region parameter, forcing a large number of client applications to update, which seriously disrupts business continuity.

[0033] Furthermore, existing distributed systems typically require all nodes to maintain version consistency, and any upgrade operation necessitates coordinating downtime windows, causing service interruptions. For example, distributed databases like Cassandra often require node-by-node updates during version iterations, which not only prolongs the upgrade cycle but also reduces overall system availability. Moreover, adding new features usually involves synchronous modifications to the code of both communicating parties, making the feature deployment process complex and time-consuming. For instance, when a social platform introduces a new recommendation algorithm, it is necessary not only to update the server-side model logic but also to adjust the client-side data parsing and display logic, significantly slowing down the iteration speed through cross-platform collaborative development.

[0034] In view of this, this application proposes a task processing method that transmits the task function itself as a transferable instruction between different runtime environments and maps it to the executable memory area of ​​the instruction executor in the form of intermediate code. This allows the task function to be executed locally on the executor system, eliminating the need for the two parties to pre-agree on data structures or shared type definitions, thus enabling cross-process / cross-device execution of the task function.

[0035] See Figure 1AThe illustrated flowchart illustrates an architecture for a task processing method. This embodiment provides a task processing method based on a layered, decoupled task instruction execution framework. The core of the framework consists of an instruction provider 11 and an instruction executor 12. The instruction provider and instruction executor form a task delegation relationship. As logically decoupled and runtime-environment-isolated independent execution entities, they run in isolated runtime environments, achieving cross-process / cross-device task transfer and dynamic execution through standardized interfaces and secure communication protocols. The workflow of this task instruction execution framework is as follows: Instruction provider 11 converts the task function into portable intermediate code and schedules the intermediate code to instruction executor in the form of an instruction package. Instruction executor 12 parses the received instruction package, maps the parsed intermediate code to a readable and executable memory area on the instruction executor's local machine, and safely runs the intermediate code in the memory area to execute the task function. Finally, the execution result of the task function of instruction executor 12 is returned to instruction sender 11.

[0036] In this framework, instruction provider 11 is responsible for compiling task functions and generating instruction packages, and may include at least the following functional modules: Code compilation module 111: Used to compile the source code of the task function to be executed into address-independent intermediate code (such as LLVM IR or WebAssembly) that is independent of hardware architecture and memory layout. Instruction encapsulation module 112: used to encapsulate the intermediate code and the configuration information required for the task function to run, and generate a structured instruction package, wherein the configuration information includes at least an execution entry identifier, code memory requirement information and access control policy; Command communication module 113: used to send the command packet to the command executor 12 through a secure communication channel.

[0037] Accordingly, instruction executor 12 is responsible for receiving and parsing instruction packets and for the trusted execution of task functions, and its internal components include at least: Instruction communication module 121: used to receive instruction packets from instruction provider 11 and forward them to instruction parsing module 122; Instruction parsing module 122: used to parse intermediate code and configuration information related to task function execution from the instruction package and submit them to instruction execution module 123; Instruction execution module 123: Based on the parsed configuration information, it allocates a readable and executable memory region locally, maps intermediate code to the memory region and executes the task function safely, and finally returns the execution result of the task function to the instruction provider 11.

[0038] As can be seen, this application breaks through the traditional task interaction mode that relies on "pre-agreed message formats" or "shared fixed interface definitions" in cross-process communication. The traditional method requires both parties to maintain strict consistency in protocol format or interface structure, and any changes need to be updated synchronously, resulting in high system coupling and high maintenance costs. In contrast, this application directly treats the task function itself as an executable instruction. After being compiled into intermediate code that is independent of hardware architecture and memory address, it is transmitted across processes or devices and loaded into the local readable and executable memory area of ​​the instruction executor for dynamic execution. This achieves complete migration and localized execution of task logic, so that the migration and execution of task logic do not require both parties to pre-agre on specific message structures or rely on unified interface definition files, thereby fundamentally decoupling the strong coupling relationship between the instruction provider and the instruction executor.

[0039] The task processing method proposed in this application can be widely applied in the following technical fields: Operating system process communication: - Inter-process communication optimization: In traditional operating systems, inter-process communication relies on mechanisms such as shared memory and message queues, but these suffer from data format constraints and permission isolation issues. This application supports directly injecting function instructions into the target process, enabling unconstrained functional expansion. For example, system service processes can dynamically load function modules provided by application processes within their own processes, improving the flexibility of system functionality.

[0040] - Microkernel Architecture Upgrade: The modular design of microkernel systems requires efficient inter-process collaboration. This application allows different processes to independently develop functional modules, which are then dynamically scheduled and executed through a framework, reducing system coupling. For example, the file system module can be provided by a third-party developer and directly deployed to the kernel space to run.

[0041] Distributed computing and edge computing: - Cross-device task migration: In a distributed cluster, the master node can dynamically distribute task functions to remote devices for execution based on the load of each slave node. For example, in an IoT scenario, edge nodes can migrate complex data processing tasks to the cloud, while the cloud returns lightweight instructions to the edge for execution.

[0042] - Architecture-based computational collaboration: Supports the transfer of function instructions between devices with different architectures (such as x86, ARM, and GPU). For example, AI (Artificial Intelligence) training tasks can allocate computationally intensive functions to GPU clusters, while control logic remains to be executed on the CPU.

[0043] Artificial Intelligence and Intelligent Systems: - AI Function Call Decoupling: Existing AI systems rely on predefined function libraries. This application allows AI models to directly receive and dynamically execute function instructions. Specifically, current AI systems use function names for function calls, passing the function description, function name, and corresponding function parameters to the AI. The AI, through its ability to analyze and understand the function description, will look up the local function by function name and call the corresponding function when needed. With the solution in this application, the function itself can be passed to the AI, which then executes the function instructions through the instruction executor, decoupling the AI ​​from the local runtime environment. Function instructions can come from either the local or remote environment.

[0044] - Edge Intelligent Inference: On edge devices, this application can dynamically allocate a portion of the computational layer of an AI model to local or remote execution, reducing latency. For example, an in-vehicle system can assign image recognition tasks to roadside units for processing, improving real-time performance.

[0045] Cloud Native and Containerization: - Serverless Architecture Enhancement: In serverless computing, this application can dynamically schedule function instructions to different container instances. For example, backend servers can use this application to implement cross-account and cross-region function calls, improving resource utilization.

[0046] - Optimized inter-container communication: Containerized applications can achieve process-level communication through frameworks, avoiding the overhead of traditional network communication. For example, in a Kubernetes cluster, microservices can directly pass function commands, improving the efficiency of inter-service collaboration.

[0047] Furthermore, the method provided in this application can also be used to implement dynamic migration scenarios of tasks in heterogeneous environments such as cross-device / cross-process collaborative systems and terminal-host device combination systems. For example, in a system consisting of a learning machine and its smart dock, the dock, as the executor, only needs to have basic code loading and execution capabilities. There is no need to upgrade the firmware of the smart dock device. All new teaching functions (such as interactive quizzes and enhanced handwriting recognition) can be generated by the mobile app (Application Program) or the cloud as the instruction provider, compiled into intermediate code, and then sent to the dock for execution. Users only need to update the mobile app to give the dock new capabilities, completely avoiding the maintenance costs and user experience degradation caused by frequent firmware flashing. Similarly, in smart home systems, devices such as smart speakers, light bulbs, and sockets, as executors, do not need to pre-install all possible functional logic. When it is necessary to add voice control strategies, linkage rules, or energy-saving algorithms, it is only necessary to update the task function through the mobile app or home hub, compile it, and send it to the local memory of the target device for execution, without upgrading the smart device firmware.

[0048] In the aforementioned task instruction execution architecture, the instruction provider and the instruction provider run in different runtime environments that are isolated from each other. This can be manifested as follows: the instruction provider and the instruction provider are two independent processes within the same device, or the instruction provider and the instruction provider are deployed on two independent physical or logical devices, such as cloud and edge devices. The task processing method provided in this example can realize remote execution of tasks across processes / devices.

[0049] See Figure 1B The illustrated flowchart represents the steps of a task processing method, which may include at least the following steps: S101, The instruction provider compiles the source code of the task function to be executed into intermediate code, which is independent of hardware architecture and memory address; Intermediate code, also known as Intermediate Representation (IR), is an abstract code form generated during the compilation of source code that lies between the high-level language and the target machine code. It does not directly correspond to the instruction set of any specific processor, nor does it depend on the specific runtime environment. Instead, it uses a unified and structured instruction format to express the logical structure and computation process of the program. As a general carrier of task logic, it supports being restored to native machine code on the instruction executor through just-in-time compilation or interpretation to complete the task execution.

[0050] In this application, the intermediate code is a portable representation generated by compiling the source code of the task function, such as LLVM IR (Low Level Virtual Machine Intermediate Representation), WebAssembly bytecode, Java Bytecode (based on the Java Virtual Machine), .NET IL (intermediate language based on the .NET runtime), or other intermediate code formats that meet the requirements of hardware architecture independence and memory address independence. The compiled intermediate code is hardware architecture independent, meaning it can be executed on different CPU architectures, and memory address independent, meaning it can be loaded into any memory location. In other words, the intermediate code supports the same functionality through local compilation or interpretation execution on devices with different hardware architectures such as x86 / ARM / RISC-V, different operating systems such as Linux / Windows / embedded systems, and different memory layouts.

[0051] Hardware architecture independence means that the same intermediate code can execute correctly on different types of central processing units (CPUs) without needing to be compiled separately for each hardware architecture. Different hardware architectures (such as x86, ARM, RISC-V) use different instruction sets, and their native machine code is incompatible with each other. Intermediate code uses unified abstract instructions that do not directly correspond to the instructions of any hardware architecture. The intermediate code hides the underlying hardware differences and achieves cross-architecture portable execution.

[0052] "Memory address independent" means that intermediate code can be loaded and executed correctly at any location in the virtual address space, without depending on a fixed memory address. During program execution, code and data are typically loaded into specific memory addresses (e.g., 0x400000 as the function's starting address). However, this memory address may change in different runtime instances or on different devices. When code directly references an absolute address (e.g., `call 0x400000`), the program will jump to an error and crash if the load location changes. This intermediate code uses symbolic references and relative addressing mechanisms to avoid hardcoding absolute addresses. For example, function calls are written as `call@add` instead of `call 0x400000`, or data access uses relative offsets such as `@global_var+offset`. When the executor maps the intermediate code to an available memory region, the just-in-time compiler dynamically calculates the actual location of `@add` based on the actual load address, combined with the symbol table and offset information, and generates the correct machine code.

[0053] In this embodiment, when compiling the task function source code into the intermediate code, the task function source code can first be compiled using a predefined compilation method to generate a hardware architecture-independent intermediate representation. This intermediate representation is then converted into binary data format and encapsulated into intermediate code containing an execution entry point identifier. The predefined compilation method can be any of the following: a compilation method pre-configured and supported by default within the instruction executor; or a specific compilation method dynamically determined based on compilation tags such as annotations, metadata, or configuration fields carried by the task function source code.

[0054] When compiling the source code of the task function into a hardware-independent intermediate representation using a specified compilation method, cross-platform compilation toolchains can be used to achieve compatibility support for multiple operating systems and instruction set architectures. Specifically, the compilation process can call adapted local compiler toolchains in different runtime environments, such as using mainstream compilers like GCC, Clang, or MSVC on Windows or Linux systems to uniformly compile the source code of the task function into a standardized intermediate representation such as LLVM IR.

[0055] Taking a simple C source file add.c as an example, its content is as follows: int add(int a, int b) { return a + b; } On the Windows platform, the source file can be compiled into LLVM IR format by executing the following command using the Clang or MinGW version of the GCC compiler integrated into the development environment (such as Visual Studio): clang -S -emit-llvm add.c -o add.ll An example of an address-independent LLVM IR for the add function can be obtained as follows: define i32 @add(i32 %a, i32 %b) { entry: %add = add nsw i32 %a, %b ret i32 %add } Subsequently, the text-formatted IR can be further converted to binary format (such as bitcode) and encapsulated as intermediate code in the form of raw binary data, facilitating network transmission and loading for execution. It should be noted that the above explanation uses the Windows platform as an example, but the compilation mechanism of this application is not limited to a specific operating system or hardware platform. In practical applications, this compilation process is supported by a unified compilation framework that can automatically adapt the compilation method based on the system type, CPU architecture, and available toolchains of the instruction executor, ensuring cross-platform consistency of the generated intermediate representation. For example, in Linux systems, the native Clang or LLVM toolchain can be called; on ARM architecture devices, cross-compilation can generate IRs with the same semantics; and on resource-constrained devices, a lightweight front-end parser can be used to directly generate IR bitcodes. Through the above methods, this application achieves a standardized conversion of task function source code to intermediate representation, shielding the differences between the underlying operating system and chip instruction sets, and providing a portable technical foundation for subsequent cross-device dynamic execution.

[0056] S102, the instruction provider determines the configuration information required for the execution of the task function and obtains the access control policy when the task function is executed, and constructs an instruction package based on the intermediate code, the configuration information and the access control policy, and sends the instruction package to the instruction executor; The configuration information represents the runtime parameters and environmental constraints related to the execution of this task function, and is used to guide the instruction executor on how and under what conditions the task function is executed. The configuration information includes at least the following categories: Runtime parameters: These include information about the inputs and runtime context required for function execution, such as input variables required for the task function to run, entry point identifiers, dependent library paths, and code memory requirements. Control information includes configuration items used to control task execution methods, resource limits, and running strategies. These do not directly affect function logic but do affect its execution behavior and system resource usage, such as the system type identifier of the instruction executor, task execution timeout, resource usage limit, and compilation optimization level (indicating which optimization strategy the just-in-time compiler should use to generate machine code). Metadata: Includes additional information used to identify, track, and manage the instruction itself, such as instruction unique identifier (ID), timestamp, source module, version number, function signature (the function's interface definition, e.g., add:i32,i32→i32 means receiving two 32-bit integers and returning one integer), checksum, etc.

[0057] The access control policy represents a set of security rules used to regulate and constrain the runtime behavior of task functions on the instruction executor, ensuring that task functions execute securely on the instruction executor with the minimum necessary permissions, preventing unauthorized access to the instruction executor's system resources or causing runtime anomalies. This access control policy may include, but is not limited to: file system access policies, including a list of allowed files / directories and access modes (read / write / execute), a list of prohibited files, and maximum file size limits; network access policies, including allowed network addresses / ports / protocols, prohibited network addresses, and maximum bandwidth limits; system call policies, including a list of allowed system calls, a list of prohibited system calls, and a list of allowed host functions; resource limitation policies, including maximum execution time / memory / CPU utilization, maximum number of open files / threads / network connections; environment variable policies, including a list of allowed / prohibited environment variables and their values; and device access policies, including a list of allowed / prohibited devices.

[0058] Instruction providers can proactively define and encapsulate access control policies based on the business requirements and security levels of task functions. For example, they can perform static program analysis on the task function's source code or intermediate code to identify its dependencies on external resources, thereby inferring the required permission scope; or extract explicit access control requirements based on permission annotations or configuration files preset by the developer in the source code; or automatically generate a least-privilege policy based on the task function's historical execution logs in the test environment through behavioral modeling. These methods can be used individually or in combination to ensure that the generated access control policy meets both functional requirements and the principle of least privilege.

[0059] Before encapsulating the instruction package, the instruction provider can verify the aforementioned configuration information, such as checking the completeness and validity of the runtime parameters in the configuration information to ensure that their type, quantity, and value range meet the interface requirements of the task function. For example, for the aforementioned add(int a, int b) function, verify whether the input variables required for the task function to run are two integer types; if the parameter type is incorrect or the quantity is incorrect, a verification failure will be triggered and an error message will be returned to avoid parsing or running abnormalities by the instruction executor due to parameter mismatch. After the verification passes, the intermediate code, the configuration information, and the access control policy can be integrated according to the predefined instruction structure to generate a standardized data package with a unified format.

[0060] After encapsulating the instruction packet, to improve the efficiency of cross-process or cross-device transmission, its structured data can be converted into a serialization format suitable for network transmission. For example, efficient and compact serialization protocols such as Protocol Buffers or JSON format can be used to significantly reduce data size, improve serialization / deserialization performance, and ensure cross-platform data consistency. Furthermore, to ensure the security of instruction transmission, the serialized instruction packet can be encrypted. For example, a symmetric encryption algorithm can be used to encrypt the entire instruction packet content, generating an encryption key and ciphertext data. This key can be distributed to the instruction executor through a secure channel (such as TLS, key exchange protocol), ensuring that only authorized instruction executors can decrypt and restore the instruction content, thereby preventing the instruction packet from being stolen, tampered with, or forged during transmission.

[0061] The encapsulated instruction package will be sent to the instruction executor. In real-world applications, the same task function may have multiple executable candidate executors, and the computing resources, network conditions, and system load of each candidate executor vary dynamically. Randomly assigning tasks without selection could lead to problems such as overload of some devices, increased task execution latency, and uneven resource utilization. To ensure efficient task scheduling and optimal overall system performance, the most suitable executor needs to be determined before sending the instruction package to the instruction executor.

[0062] Specifically, in this embodiment, when the task function corresponds to multiple executable candidate executors, based on the running status information of each candidate executor and at least one setting information, a candidate executor is selected from the multiple candidate executors as the instruction executor, and the instruction packet is sent to the instruction executor. The setting information includes at least a preset load balancing strategy and a proximity routing strategy based on network topology; the multiple candidate executors represent different processes on the same device, or the multiple candidate executors represent multiple different devices interconnected in the network. In other words, the multiple candidate executors can have two deployment forms: Different processes on the same device: For example, running multiple isolated sandboxed runtime instances on an edge computing device, each instance can serve as an independent candidate executor; Multiple different devices interconnected in a network: For example, in a distributed system, multiple edge nodes, cloud servers, or terminal devices may all have the ability to execute the task function, forming a cross-device candidate execution set.

[0063] To achieve intelligent scheduling, the device status monitoring component can collect the running status information of each candidate executor in real time, including but not limited to: CPU utilization, memory usage, available stack space, current number of concurrent tasks, network round-trip latency (RTT) and bandwidth, etc. Based on this status information, combined with the preset load balancing strategy / network topology-based nearest routing strategy, all candidate executors are evaluated and ranked.

[0064] The load balancing strategy can be configured in multiple modes, such as: minimum load priority, which prioritizes the device with the lowest CPU and memory utilization; or, minimum latency priority, which prioritizes the node with the lowest network latency to the instruction provider; or, weighted average score minimum priority, which assigns weights to each indicator (e.g., CPU 40%, memory 30%, network 30%) to calculate the overall score; or, affinity scheduling, which prioritizes devices that have successfully executed similar tasks to improve cache hit rate and execution efficiency.

[0065] For example, for a candidate executor consisting of devices A, B, and C, the device status monitoring module obtains the following information in real time: Device A: CPU utilization is 88%, memory usage is 90%, indicating a high load. Device B: CPU utilization is 32%, memory usage is 45%, network latency is low (RTT<10ms), and resources are plentiful; Device C: CPU utilization is 55%, memory usage is 60%, but network latency is high (RTT>50ms); A comprehensive evaluation can be conducted based on the load balancing strategy of "minimum load priority + network latency weighting" to determine that device B has the best execution conditions. Therefore, it is selected as the instruction executor for this task, and the encapsulated instruction package is sent to the runtime environment of device B through a secure communication channel.

[0066] The network topology-based proximity routing strategy prioritizes the candidate executor with the lowest communication cost based on the network topology relationship between the instruction provider and each candidate executor, such as physical distance, network hop count, link quality, latency, and bandwidth. This communication cost can be understood as geographical proximity, shorter network paths, lower communication latency, and more abundant bandwidth, thereby reducing data transmission overhead, lowering end-to-end latency, and improving task response speed and overall system throughput. For example, devices within the same local area network (LAN) have lower communication costs than devices across a wide area network (WAN); devices communicating via direct links have lower communication costs than devices requiring multiple routers; and links with low RTT (Round-Trip Time) and low packet loss rate are considered to have lower communication costs.

[0067] For example, for a candidate executor consisting of devices D, E, and F, the device status monitoring module obtains the following information in real time: Device D: CPU utilization is 30%, memory usage is 40%, network latency RRT=10ms, available network bandwidth is 100Mbps, and the network topology is on the same local area network. Device E: CPU utilization is 20%, memory usage is 30%, network latency RRT=80ms, available network bandwidth is 50Mbps, and the network topology is a cross-city backbone network; Device F: CPU utilization is 60%, memory usage is 70%, network latency RRT=5ms, available network bandwidth is 800Mbps, and the network topology is directly connected within the same data center; Considering only the nearest routing strategy, device F can be used as the executor of this task function. However, considering both load balancing and network proximity routing strategies, while device F has an excellent network, its high CPU and memory load and numerous concurrent tasks may create execution bottlenecks. Although device E has a slightly lower load, its RTT is as high as 80ms and its bandwidth is limited, which will introduce significant latency when transmitting intermediate code and returning results. In contrast, device D has a moderate load, is located on the same local area network, has an RTT of only 0ms, and sufficient bandwidth. It is also the "nearest" node in the network topology, so device D can be used as the executor of this task function.

[0068] The executor selection mechanism based on the above-mentioned running status and load balancing strategy enables dynamic adjustment of task allocation according to the real-time system status, avoids resource waste caused by static scheduling, and prioritizes nodes with idle resources and fast response, thereby reducing task execution latency.

[0069] Before sending the instruction package to the instruction executor, the system can first check the executor's runtime environment to verify whether it meets the dependencies of the task function execution, such as the existence of required dynamic link libraries or specific software versions. For example, the task function execution may depend on the libmath.so dynamic link library, and the system will check whether the library file exists on the execution device. If it does not exist, the system will prompt that the dependency library is missing, avoiding the instruction failing to run on the execution device due to environment deficiencies and ensuring the feasibility of instruction execution in advance.

[0070] Based on the cross-process or cross-device remote task execution mechanism between the instruction provider and the instruction executor in this embodiment, the instruction package generated by the instruction provider needs to be transmitted securely and reliably to the instruction executor. Since communication boundaries and security threat models differ across deployment scenarios, to balance transmission efficiency and security, an appropriate communication channel and transmission protocol can be dynamically selected based on the deployment relationship between the instruction provider and the instruction executor. Therefore, when sending the instruction package to the instruction executor: S201, if the instruction executor and the instruction provider are different processes of the same device, the instruction packet is transmitted to the instruction executor through the local inter-process communication channel; See Figure 2 The exemplary diagram illustrates a communication method in which an instruction provider sends an instruction packet to an instruction execution method. The instruction communication module 113 of the instruction provider includes a local communication channel 1131 and a cross-end communication channel 1132. Correspondingly, the instruction communication module 121 of the instruction execution method includes a local communication channel 1211 and a cross-end communication channel 1212.

[0071] When cross-process communication occurs within the same device, the instruction provider sends instruction packets to the instruction executor through local communication channel 1131, and the instruction executor receives instruction packets from local communication channel 1211. To ensure communication security, the instruction packets can be transmitted through an encrypted local inter-process communication channel: the instruction communication module 113 of the instruction provider selects a local inter-process communication mechanism that supports access control based on the process security context of the instruction executor, and securely delivers the instruction packets to the instruction executor, preventing unauthorized processes from intercepting or tampering with instruction data.

[0072] S202, if the instruction executor and the instruction provider are different devices, the instruction packet is transmitted to the instruction executor through the Socket network connection between the instruction executor and the instruction provider.

[0073] When cross-device network communication is performed, the instruction provider and the instruction executor establish an end-to-end connection using a Socket network communication protocol (such as TCP or TLS over TCP). The instruction provider initiates a network request to the instruction executor through the cross-end communication channel 1132 and sends instruction packets based on the instruction executor's network address information, such as IP address and port. The instruction executor receives instruction packets from the cross-end communication channel 1212, completing the transfer of the task function from the provider to the executor.

[0074] S103, after receiving the instruction packet, the instruction executor maps the machine code to a readable and executable memory area in its local memory based on the configuration information, and executes the machine code in the memory area based on the configuration information and the access control policy to execute the task function, and returns the execution result of the task function to the instruction provider.

[0075] Upon receiving the instruction packet, the instruction executor can perform a preliminary check to ensure the packet is intact and undamaged. If the instruction packet has been serialized and encrypted by the instruction provider, the instruction executor uses a pre-negotiated key to decrypt the encrypted packet and deserializes the decrypted data, converting the serialized instruction data into a structured, processable form, thereby restoring the encrypted binary data to the original instruction information.

[0076] The instruction packet is parsed to extract intermediate code, configuration information, and access control policies, which are then placed in a temporary buffer. To prevent security risks caused by malicious tampering or transmission errors, the system performs integrity and validity verification on the instruction packet after parsing. This verification may include at least digital signature verification, format compliance checks, and parameter validity checks. If any verification fails, the instruction packet is discarded, and a security audit log is recorded, including information such as error type, source address, and timestamp. The system also reports the exception to the instruction provider and terminates subsequent processing. For example, the executor calculates the hash value of the intermediate code's byte stream and compares it with the hash value carried in the instruction packet. If the hash values ​​do not match, the code is determined to have been tampered with during transmission, execution is refused, and a security audit log is recorded.

[0077] Furthermore, permission checks can be performed. This involves determining whether the access requests to system resources are within the authorized scope based on the access control policies carried in the command package or loaded from the local policy library. The permissions of the command package for local execution on the execution end are verified to ensure it only possesses legal and limited permissions (such as ordinary user permissions), preventing unauthorized access to sensitive system resources such as critical system files, low-level hardware interfaces, and sensitive registry keys. To further ensure task executability, it can also verify whether the local runtime environment meets the dependencies required for the command package's operation. For example, it can confirm that required dynamic link libraries are installed and their versions are correct, or that specific software environments are configured correctly. If dependencies are not met, execution of the command is refused, and an error message is sent to the command provider.

[0078] When verifying the validity of the instruction package, address-independent intermediate code needs to be mapped to a readable and executable memory region on the instruction executor's local machine. Since this intermediate code is an address-independent intermediate representation, it is independent of the specific hardware architecture and exists only as static data that can be parsed and compiled, lacking direct execution capability. Therefore, the runtime engine in the instruction executor parses the intermediate code in the instruction package into an internal intermediate representation, and then optimizes and generates code using a just-in-time (JIT) compiler to generate machine code for the target architecture supported by the instruction executor. This machine code is then loaded into a valid readable and executable memory region.

[0079] Based on this, the parsed intermediate code can be placed in a temporary cache / normal data memory. The runtime engine uses just-in-time (JIT) compilation technology to locally compile the intermediate code in the instruction package into machine code supported by the CPU architecture of the instruction executor, and writes the machine code into this readable and executable memory area. The intermediate code itself is stored in normal heap memory or a read-only data segment, serving only as input data for the compilation process. It is not copied or resides in this readable and executable memory area, thus ensuring strict separation of data and code. For example, if the instruction executor is an x86_64 architecture, the intermediate code is compiled into native machine code adapted to the x86-64 instruction set architecture (ISA).

[0080] This readable and executable memory region is used to store the native machine instructions generated from the intermediate code through just-in-time compilation. This memory region can be obtained in the following way: based on the code memory requirement information in the configuration information, a virtual memory region is requested from the operating system of the instruction executor, and the access permissions of this memory region are set to readable and executable. That is, by calling the operating system's memory management interface, the access permissions of this memory region are set to readable and executable (PROT_READ | PROT_EXEC), while write permissions are prohibited to satisfy the W^X (WriteXOR Execute) principle in modern system security mechanisms, preventing code injection or tampering attacks.

[0081] On mainstream Unix-like systems (such as Linux and macOS), this readable and executable memory region can be requested using the mmap system call, for example: void* code_memory = mmap( NULL, / / The starting address is selected by the system. code_size, / / Memory size PROT_READ | PROT_EXEC, / / Permissions: Readable, Executable MAP_PRIVATE | MAP_ANONYMOUS, / / Private anonymous mapping -1, 0 / / No associated file ); If the instruction executor does not support the mmap interface, a contiguous block of physical memory can be allocated through the Memory Management Unit (MMU), and this physical memory can be mapped into an independent virtual address space. Permission bits in the page table entries can be configured to explicitly allow the memory region to have read and execute attributes, but prohibit writing. After completing the virtual memory layout, a usable code load address is returned. Either of these methods can create a controlled, secure memory context that can be used to execute dynamically generated machine code.

[0082] The compiled machine code is written to the previously allocated readable and executable memory region. At this point, the memory block becomes a valid program code segment, ready to be directly fetched and executed by the central processing unit (CPU). The runtime engine of the instruction executor executes the machine code in this memory region based on the configuration information and the access control policy to execute the task function. Simultaneously, the starting address of the machine code in the memory region is recorded or cached and associated with the function identifier of the corresponding intermediate code. When accessing the machine code subsequently, the entry address can be determined based on the starting address of the machine code in the memory region, allowing the CPU to schedule and execute the machine code.

[0083] See Figure 3 The illustrative diagram illustrates a flowchart of running the intermediate code within a readable and executable memory region to execute a task function. The instruction executor executes the task function through the following steps: S301, determine the entry address of the task function in the executable memory region based on the function execution entry information in the configuration information; Function execution entry point information refers to metadata explicitly specified in the instruction package configuration information that identifies the starting execution location of a task function. It can include any of the following forms: a function symbol name, such as a string identifier like _start, main, or process_data, corresponding to the function name defined in the intermediate code; an offset address, representing the byte offset relative to the start of the code segment, for example, +0x120 indicates that the entry point is 288 bytes off from the executable memory base address; and an entry label, a pre-defined label in the intermediate code or linker script used to indicate the program entry point. This function execution entry point information is generated by the instruction provider during the instruction package encapsulation stage based on the compilation results of the task function and is transmitted to the instruction executor along with the configuration information.

[0084] The entry address represents the actual memory address of the task function in the local executable memory region, that is, the virtual memory location of the first instruction of the compiled machine code. After the runtime engine completes just-in-time compilation and writes the machine code into a readable and executable memory region, this memory region has a base address, and the entry address is equal to the sum of the base address and the offset.

[0085] S302, the entry address is converted into a function pointer, and the function pointer is called to start the execution of the task function; The entry address is cast to a function pointer of the appropriate type, such as a parameterless, return-value-free function pointer type `void (*)()`, or a more precise type defined based on the actual function signature (such as `int (*)(const char*, size_t)`). This conversion incurs no runtime cost; it is merely a semantic encapsulation of the memory address.

[0086] The execution of the function pointer call triggers the CPU to update the current instruction pointer to that entry address, and then reads and decodes machine instructions one by one from that address, formally entering the core logic execution phase of the task function. Essentially, this operation transfers program control to the memory address of the instruction executor, allowing the CPU to read and execute machine instructions one by one from that location, thereby activating the core logic of the task function.

[0087] S303, during the execution of the task function, the access control policy is used to monitor the running behavior of the task function in real time, and the execution of the task function is terminated when abnormal access behavior is detected.

[0088] After a task function is initiated and executed via function pointer calls or similar methods, the instruction executor performs real-time, dynamic security monitoring of its execution process to ensure that its behavior remains within preset security boundaries. This monitoring mechanism, based on access control policies carried in the configuration information or loaded from a local policy library, continuously monitors the task function's execution behavior and terminates its execution upon detecting anomalies or unauthorized operations.

[0089] Access control policies define the permitted scope of operations for task functions, including at least the types of callable host interfaces, accessible resource paths (such as file directories and network addresses), maximum execution time, and memory usage limits. Therefore, real-time monitoring of task function behavior includes at least the following: Security monitoring: Used to detect the presence of security threat behaviors, which may include, but are not limited to: attempting to execute illegal instructions such as privileged instructions HLT and IN / OUT, or initiating illegal memory access such as out-of-bounds access or jumping to non-code segments, or dynamically modifying its own code or attempting to inject code, etc. Exception monitoring: Used to capture low-level runtime exceptions triggered during the execution of task functions. Runtime exceptions may include, but are not limited to: segmentation fault (i.e., accessing unmapped memory), illegal instruction exception (i.e., executing invalid or unsupported machine code), stack overflow, etc. Access monitoring: Used to record task access operations to resources such as files, networks, memory, and devices, forming audit logs to support post-event traceability and behavior analysis.

[0090] If the monitoring module detects any violation or abnormal event, the system will immediately terminate the execution of the task, release the relevant resources, and report the error information to the instruction provider or the local security management module to achieve fault isolation and rapid response.

[0091] The monitoring includes at least: security monitoring (preventing unauthorized commands or unauthorized operations), anomaly monitoring (capturing anomalies such as segmentation faults and unauthorized commands), and access monitoring (recording resource access operations). If an anomaly occurs, command execution is immediately terminated and the error is handled.

[0092] If an anomaly is detected in any monitoring dimension during the monitoring process, the execution of the task function will be terminated immediately. This can be done by sending a termination signal to the execution thread or by actively jumping to a preset termination routine, thus forcibly exiting the current execution context. Simultaneously, the system generates an error report, including the anomaly type, time of occurrence, and details of the violation, and feeds this error information back to the instruction provider or local security management module via the instruction communication module, achieving fault isolation and rapid response.

[0093] When the task function is completed, the execution result of the instruction executor can be serialized and converted into a cross-platform compatible data format. The serialized execution result is then encapsulated into a response message through the instruction communication module and reliably transmitted back to the instruction provider via the established communication channel.

[0094] When the task function finishes execution, the readable and executable memory area is released, and other related resources such as temporary variables, symbol tables, JIT compilation caches and other runtime contexts are reclaimed. Response data or error information is returned to the instruction provider based on the execution result.

[0095] This disclosure provides a cross-runtime environment task processing method based on task functions. It transmits the task function itself as an instruction in different runtime environments, mapping the task function to the executable memory of the instruction executor. This allows the instruction executor to run the task function in the system's local memory, breaking through the dependence of traditional remote invocation mechanisms on fixed interface definitions and preset communication protocols. It achieves autonomous encapsulation and on-demand delivery of task logic. By encapsulating the task function in intermediate code independent of hardware architecture and memory address, and combining it with the configuration information and access control policies required for execution, a complete, independently transmittable and executable instruction package is constructed. This enables secure, dynamic, and tightly coupled task execution in a runtime environment where the instruction provider and executor are completely isolated.

[0096] The cross-process / device execution of task functions provided in this application effectively overcomes the strong dependence of traditional message queues and RPC frameworks on communication formats and interface definitions. It eliminates the need for pre-agreed message structures or shared IDL files between parties. When either party independently upgrades the task logic, the other party does not need to update or recompile synchronously, significantly reducing system maintenance costs and improving business continuity. Furthermore, the method provided in this application supports dynamic, uninterrupted feature upgrades and extensions. Newly added or optimized task functions can be independently deployed and executed immediately, avoiding service interruptions caused by version inconsistencies in distributed systems and significantly shortening development iteration cycles. In addition, by embedding access control policies in the instruction package and implementing runtime monitoring during code loading and execution, it avoids the privacy leakage risks caused by excessive authorization in traditional permission transfers and achieves real-time interception and response to illegal operations and abnormal behaviors, constructing a trusted dynamic execution environment.

[0097] In some embodiments, to reduce the communication overhead caused by repeatedly transmitting intermediate code and improve task scheduling efficiency, this embodiment proposes a code caching and on-demand transmission mechanism based on function identifiers. Specifically, each piece of intermediate code is assigned a globally unique function identifier; the instruction executor can locally retain the memory region for a preset time window based on the function identifier of the intermediate code corresponding to the machine code that has been mapped to the memory region, and release the memory region when the preset time window expires. This allows associating the machine code that has been mapped to the instruction executor's memory region with the unique function identifier of the intermediate code corresponding to that machine code.

[0098] For example, setting a preset time window of 1 hour, assuming the instruction executor receives an instruction packet carrying intermediate code with the function identifier FUNC_RESIZE_V3_8A2F, after compiling the intermediate code into machine code and mapping it to memory area Area1, a 1-hour timer is started. When the instruction executor completes the execution of the machine code based on the configuration information carried in the instruction packet, the memory area remains unreleased until the timer expires and is automatically released. In this approach, if another instruction packet with the function identifier FUNC_RESIZE_V3_8A2F is received within 1 hour of the initial instruction packet, there is no need to compile it into machine code or map it to memory; the machine code can be directly scheduled from the reserved memory area Area1 to execute the task function.

[0099] Therefore, when it is necessary to transmit the intermediate code of any task function to be executed to the instruction executor, when constructing an instruction package based on the intermediate code, the configuration information, and the access control policy, the unique function identifier of the intermediate code can be obtained first. Further, it is checked whether there is a transmission record within the preset time window prior to the current moment showing that the intermediate code corresponding to the function identifier was sent to the instruction executor. If not, the function identifier, the intermediate code, the configuration information, and the access control policy are encapsulated to generate the instruction package; otherwise, the function identifier, the configuration information, and the access control policy are encapsulated to generate the instruction package; the instruction package does not contain the intermediate code.

[0100] In other words, the instruction provider can dynamically decide whether to include intermediate code in the instruction packet based on historical transmission records, thereby avoiding the repeated transmission of the same intermediate code to the instruction executor who still has valid cached intermediate code. For example, suppose the function identifier of function func_v1 is "F001", and the preset time window is 30 minutes; if the instruction provider has already sent the intermediate code corresponding to F001 to device X 15 minutes ago, then when calling func_v1 again at the current moment, it only needs to send a lightweight instruction packet consisting of the function identifier F001, configuration information (including the parameter information required for function execution during this call), and access control policy, without having to repeatedly send the intermediate code, thereby reducing the transmission load and saving bandwidth and improving the response speed of task function execution across environments.

[0101] In this embodiment, the preset time windows of the instruction sender and the instruction executor are of the same duration, so that the instruction provider and the instruction executor have consistent judgments on the cache validity of the same intermediate code. This facilitates collaborative management of the transmission and memory cache lifecycle of the intermediate code, thereby ensuring the validity of the executor's cache and the reliability of system operation while avoiding redundant transmission.

[0102] Under the aforementioned caching and on-demand transmission method, after receiving the instruction packet, before compiling the intermediate code in the instruction packet into machine code, the instruction executor can first query the memory regions locally reserved by the instruction executor to see if there is a target memory region that matches the function identifier in the instruction packet. If it exists, the machine code is executed directly in the target memory region based on the configuration information and the access control policy to execute the task function; If the instruction package does not exist, and if the instruction package includes intermediate code, the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor, and the machine code is mapped to a locally readable and executable memory region, and the memory region is kept unreleased within a preset time window; otherwise, the instruction executor returns a function identifier mismatch indication to the instruction provider to request the sending of the intermediate code corresponding to the function identifier in the instruction package.

[0103] In other words, the instruction executor uses function identifiers to quickly reuse loaded code, triggering the compilation process only when the cache expires or the code is called for the first time. For example, after receiving an instruction packet containing the function identifier "F001", device X checks its local cache and finds that the machine code corresponding to F001 is still valid for 30 minutes. It then directly calls the machine code corresponding to the function identifier F001 in the memory area that is not released and executes it. If the memory area corresponding to the function identifier has been released or this is the first time the task function pointed to by the function identifier has been called, it further checks whether the instruction packet contains intermediate code. If it does, it is compiled and loaded; otherwise, it returns an "F001 miss" error, and the instruction provider resends the complete instruction packet.

[0104] In this embodiment, by introducing globally unique function identifiers, a collaborative code caching and on-demand transmission mechanism based on a unified time window is constructed between the instruction provider and the instruction executor. When the instruction provider repeatedly calls intermediate code within the cache validity period, it does not need to repeatedly transmit the intermediate code; it only transmits the lightweight function identifier, configuration parameters, and access policies, saving bandwidth resources. The instruction executor can directly reuse local machine code already mapped to the memory area within the cache validity period, avoiding the delays of repeated compilation and memory mapping, shortening the task function startup time, and improving task scheduling and execution efficiency. In addition, the memory area is automatically released after setting a preset time window to prevent memory leaks caused by unlimited cache accumulation, balancing performance and resource security.

[0105] In some embodiments, in order to reduce the network overhead caused by frequent establishment and disconnection of communication connections and improve the efficiency of multi-function deployment, when sending the instruction package to the instruction executor, the instruction packages encapsulated by multiple task functions to be executed can be aggregated into a batch transmission unit, and the batch transmission unit can be sent to the instruction executor through a single communication connection.

[0106] After receiving the batch transmission unit, the instruction executor compiles each intermediate code contained in the batch transmission unit locally, maps the compiled machine code to a readable and executable memory area allocated for the machine code, and establishes an association between the function identifier of each intermediate code and the memory area mapped to the corresponding machine code, so as to call and execute from multiple memory areas based on the function identifier in the instruction packet subsequently sent by the instruction executor.

[0107] In other words, this embodiment merges the process of issuing multiple independent task functions into a single batch operation, with the executor uniformly completing the compilation, memory mapping, and cache registration. Subsequent calls only need to be triggered by the lightweight function identifier, without the need for repeated transmission or initialization.

[0108] For example, suppose the cloud scheduler needs to send three image processing functions to be executed to the edge device E5: resize_image (identifier F001), denoise (F002), and encode_jpeg (F003). In this embodiment, instead of sending the three functions separately over three separate connections, the scheduler packages the three instruction packets corresponding to these three functions into a single batch transmission unit and sends it over a single TLS connection. After receiving the data, E5 compiles the intermediate code of F001 to F003 sequentially, loads them into memory areas Area1 to Area3 respectively, and establishes a mapping table: F001 → Area1, F002 → Area2, F003 → Area3. When the instruction provider initiates a pipeline task of "scaling first, then denoising, and finally encoding", the scheduler only needs to send three lightweight call instructions (containing only function identifiers and parameters) consecutively. E5 can then directly schedule the corresponding machine code from the cached memory area for execution, without needing to transmit code again or rebuild the connection.

[0109] In this embodiment, a collaborative mechanism of batch preloading and on-demand invocation is adopted, which can reduce the overhead of network connection establishment and release, and reduce the bandwidth pressure caused by repeated transmission of intermediate code. At the same time, by centralizing compilation and memory allocation, frequent small-granularity memory allocation and release are avoided, improving the memory management efficiency of the execution end and the overall system throughput. In addition, the pre-built multiple function caches provide a low-latency, high-concurrency execution foundation for complex task function chains (such as data pipelines and combinatorial AI inference).

[0110] In some embodiments, to enhance the security of cross-runtime environment task invocation and prevent the instruction package from being illegally intercepted, replayed, or executed without authorization, the instruction provider may obtain an access token for the task function to be executed from an authentication center before constructing the instruction package, and encapsulate the access token together with the instruction package; the access token includes a token validity period and an audience field; the field value of the audience field points to a set of executor identifiers that can call the task function to be executed.

[0111] Upon receiving the instruction packet, the instruction executor verifies whether the access token in the instruction packet is within its validity period and whether the instruction executor's own identifier is within the range of the audience field value. If both verifications pass, the intermediate code in the instruction packet is locally compiled into machine code supported by the instruction executor, and the subsequent machine code mapping and execution process continues. Otherwise, the instruction packet is rejected, and the instruction provider is returned a corresponding execution result indicating rejection.

[0112] In other words, this embodiment introduces a fine-grained authorization mechanism based on short-term access tokens, and encodes the authorization scope of task function calls into the token. The executor performs double verification (timeliness + authorization scope) at runtime, thereby achieving dynamic and reliable control over the task distribution process. For example, suppose the cloud scheduler needs to issue a sensitive data anonymization function (function identifier F_DEID_2025) to the edge device E7. The scheduler first requests an access token from the authentication center. The authentication center issues a JWT format token, which includes: validity period: current time + 5 minutes; audience field: ["E7", "E9"], indicating that only these two devices are allowed to execute the function.

[0113] The scheduler encapsulates the token along with intermediate code, configuration information, etc., into an instruction packet and sends it. After receiving the packet, E7 parses the access token, confirms that the current time has not expired, and that its own device ID "E7" is included in the audience field, thus verifying the validity. It then compiles and executes the intermediate code in the instruction packet. However, if an attacker forwards the instruction packet to E8, the latter will directly refuse to execute it because it is not in the audience field, even if the token has not expired.

[0114] In this embodiment, by adopting a short-term, targeted, and verifiable access token mechanism, the abuse of instruction packets over a long period of time or unauthorized calls across devices can be effectively prevented, thereby improving the security of function instruction transmission in open or semi-trusted network environments. At the same time, since the token is issued by a trusted certification center and has clear time limits and audience restrictions, there is no need to pre-set complex permission rules on the executor, simplifying the management and deployment of security policies and providing reliable security for cross-domain dynamic code execution.

[0115] To enable those skilled in the art to better understand the task processing method provided in this application, specific case scenarios of applying the task processing scheme are provided below to illustrate the task processing method.

[0116] (1) Case Scenario 1: Migration of Distributed AI Inference Tasks Device A (edge ​​server, CPU load 80%) needs to execute the image recognition task image_recognize(). The task is then migrated to device B (idle GPU server). The task migration process using the task processing method of this application is as follows: Step 1: Instruction provider operates (Device A) ① Code compilation: Compile the C++ implementation of the image_recognize() function into an address-independent intermediate representation LLVM IR that is independent of specific hardware architecture; and obtain the configuration information required for the task function to execute: the input parameter is the image data uint8_t* image_data, the output is the recognition label string label, and other metadata.

[0117] ② Resource scheduling: Device B's GPU utilization is detected to be 20%, network latency is 5ms, and its priority is higher than other devices. Device B is selected as the instruction executor, and instruction packets are sent through the Socket network connection with Device B.

[0118] ③ Instruction encapsulation: The LLVM IR code and configuration information required for task function execution are encapsulated into an instruction package, which is then encrypted using TLS (Transport Layer Security) and signed using ECDSA (Elliptic Curve Digital Signature Algorithm), along with the certificate of device A.

[0119] ④ Instruction transmission: The encrypted instruction packet, along with the digital signature and certificate, is transmitted to device B via the Socket network connection between device A and device B.

[0120] Step 2: Instruction executor operates (Device B) ① Command reception: Receive command packets via the Socket network with device A; ② Security verification: Verify the certificate of device A through the CA root certificate and verify the digital signature (takes 1ms), and check library dependencies, such as confirming that the OpenCV library is loaded locally (resolved by the dynamic linker); ③ Instruction parsing: After the integrity and signature verifications pass, the instruction packet is decrypted, which takes 2ms. The decrypted LLVM IR code is then placed into the local temporary cache space of the instruction executor. ④ Code mapping: Use mmap to create a memory region, which includes a code region and a data region. Mark the code region as an executable region. Compile the LLVM IR code in just-in-time into native machine code supported by the system architecture of the instruction executor. Write the native machine code into the code region and write the input parameters - image data required for function execution in the configuration information into the data region. ⑤ Execution control: Execute the native machine code in the code area to call the image_recognize() function. The GPU accelerates the image processing, which takes 15ms (about 5 times faster than the CPU processing speed of device A). The execution result, such as the identified label being "cat", is returned to device A via a Socket network connection.

[0121] Based on actual testing, the above task migration resulted in the following performance improvements: Task execution time decreased from 80ms on device A to 15ms on device B, a latency reduction of 81%; CPU load on device A decreased to 60%, GPU utilization on device B increased to 40%, and cluster resource utilization improved by 25%. Using the task migration method provided in this application, if the recognition algorithm needs to be updated subsequently, only the function source code of the new recognition algorithm needs to be compiled on device A and the instruction packet needs to be sent; device B does not need to be upgraded. Furthermore, the instruction packet transmission is encrypted throughout, and device B executes it using local GPU privileges, preventing device A from directly accessing hardware resources.

[0122] (2) Case Scenario 2: Distributed Image Rendering Task Device C (rendering server, CPU load 85%) needs to handle 3D image rendering tasks. The task migration process, using the task processing method of this application, is as follows: Step 1: Instruction provider operates (Device C) ① Code compilation: Compile the rendering function into LLVM IR code and obtain the configuration information required for the execution of the task function, such as 3D model data as input and rendered images and other metadata as output.

[0123] ② Resource scheduling: Device status monitoring shows that device D's GPU utilization is 20% and network latency is 5ms, and it has been added to the execution list.

[0124] ③ Instruction encapsulation: The LLVM IR code and configuration information required for task function execution are encapsulated into an instruction package, which is then encrypted using TLS (Transport Layer Security) and signed using ECDSA (Elliptic Curve Digital Signature Algorithm), along with the certificate of device C.

[0125] ④ Instruction transmission: The encrypted instruction packet, along with the digital signature and certificate, is transmitted across devices C and D via a Socket network connection.

[0126] Step 2: Operation by the instruction executor (Device D) ① Command reception: Receive command packets via the Socket network with device C; ② Security verification: Verify the certificate of device C through the CA root certificate, verify the digital signature, confirm that only local GPU permissions are used, and check rendering library dependencies; ③ Instruction parsing: After the integrity and signature verifications pass, the instruction packet is decrypted, which takes 2ms. The decrypted LLVM IR code is then placed into the local temporary cache space of device D. ④ Code Mapping: Use mmap to create an executable memory region, compile the LLVM IR code into native machine code supported by the system architecture of device D, write the native machine code into the code area, and process the input parameters required for function execution in the configuration information—model data—through parameter parsing.

[0127] ⑤ Execution control: The instruction executor calls the native machine code, the GPU renders the image (taking 100ms, which is about 4 times faster than the CPU rendering image on device C), and the execution result is serialized and returned to device C.

[0128] Based on actual testing, the above task migration resulted in the following performance improvements: The rendering task time was reduced from 400ms on device C to 100ms on device D, improving efficiency by 75%; the CPU load on device C was reduced to 70%, and the GPU utilization on device D was increased to 40%, resulting in a more balanced distribution of cluster resources.

[0129] Using the task migration method provided in this application, if the rendering algorithm is subsequently upgraded, only the upgraded rendering algorithm code needs to be recompiled on device C and sent to device D. Device D does not need to undergo interface or firmware upgrades. Furthermore, the instruction transmission process is encrypted, and device D executes the instructions using local privileges, avoiding the risk of device C directly accessing the GPU.

[0130] Corresponding to the embodiments of the aforementioned task processing methods, see [link to relevant documentation]. Figure 4 As shown, this application also provides an embodiment of a task processing apparatus, the apparatus comprising: The task sending module 401 is configured to: compile the source code of the task function to be executed into intermediate code, which is independent of hardware architecture and memory address; determine the configuration information required for the execution of the task function and obtain the access control policy when the task function is executed; construct an instruction package based on the intermediate code, the configuration information and the access control policy, and send the instruction package to the instruction executor; wherein the instruction provider and the instruction executor run in different runtime environments that are isolated from each other. The task execution module 402 is configured such that, after receiving the instruction packet, the instruction executor maps the machine code to a readable and executable memory area in the local memory of the instruction executor based on the configuration information, executes the machine code in the memory area based on the configuration information and the access control policy to execute the task function, and returns the execution result of the task function to the instruction provider.

[0131] In some embodiments, when the task sending module is configured to send the instruction packet to the instruction executor, it includes: When the instruction executor and the instruction provider are different processes on the same device, the instruction packet is transmitted to the instruction executor through a local inter-process communication channel; when the instruction executor and the instruction provider are on different devices, the instruction packet is transmitted to the instruction executor through a Socket network connection between the instruction executor and the instruction provider. In some embodiments, when the task sending module is configured to compile the source code of the task function to be executed into intermediate code, it includes: Based on the compilation tags of the task function source code, the compilation method of the task function source code is determined; the task function source code is compiled using the compilation method to generate an intermediate representation independent of hardware architecture; the intermediate representation is converted into binary data format and encapsulated into intermediate code containing an execution entry point identifier; In some embodiments, when the task execution module is configured to map the machine code to a readable and executable memory region in the instruction executor's local memory based on the configuration information, the following is included: Based on the code memory requirement information in the configuration information, a memory region is requested from the operating system of the instruction executor, and the access permissions of the memory region are set to be readable and executable; the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor, and the machine code is written into the memory region; In some embodiments, when the task execution module is configured to execute the machine code in the memory region based on the configuration information and the access control policy to execute the task function, it includes: Based on the function execution entry information in the configuration information, the entry address of the task function in the memory region is determined; the entry address is converted into a function pointer, and the function pointer is called to start the execution of the task function; during the execution of the task function, the running behavior of the task function is monitored in real time through the access control policy, and the execution of the task function is terminated when abnormal access behavior is detected.

[0132] In some embodiments, when the task sending module is configured to send the instruction packet to the instruction executor, it includes: When the task function corresponds to multiple executable candidate executors, based on the running status information of each candidate executor and at least one setting information, a candidate executor is selected from the multiple candidate executors as the instruction executor, and the instruction packet is sent to the instruction executor; wherein, the setting information includes at least a preset load balancing strategy and a proximity routing strategy based on network topology; the multiple candidate executors represent different processes in the same device, or the multiple candidate executors represent multiple different devices interconnected in the network.

[0133] In some embodiments, the intermediate code corresponding to the machine code has a unique function identifier; the instruction executor retains the memory region for machine code that has been mapped to the memory region within a preset time window, and releases the memory region when the preset time window expires; When the task sending module is configured to construct an instruction package based on the intermediate code, the configuration information, and the access control policy, the following steps are included: obtaining a unique function identifier for the intermediate code; if there is no sending record of sending the intermediate code corresponding to the function identifier to the designated executor within the preset time window before the current time, then encapsulating the function identifier, the intermediate code, the configuration information, and the access control policy to generate the instruction package; otherwise, encapsulating the function identifier, the configuration information, and the access control policy to generate the instruction package; the instruction package does not contain the intermediate code.

[0134] In some embodiments, after receiving the instruction packet, the task execution module further includes: Check whether there is a target memory region that matches the function identifier in the instruction package in each memory region locally reserved by the instruction executor; If it exists, the machine code is executed directly in the target memory region based on the configuration information and the access control policy to execute the task function; If it does not exist, then if the instruction package includes intermediate code, the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor; otherwise, an indication message indicating that the function identifier was not matched is returned to the instruction sender to request the sending of the intermediate code corresponding to the function identifier in the instruction package.

[0135] In some embodiments, when the task sending module is configured to send the instruction package to the instruction executor, it includes: aggregating the instruction packages encapsulated by multiple task functions to be executed into a batch transmission unit, and sending the batch transmission unit to the instruction executor through a single communication connection; The task execution module is configured such that after receiving the batch transmission unit, the instruction executor performs local compilation of each intermediate code contained in the batch transmission unit, maps the compiled machine code to a readable and executable memory area allocated for the machine code, and establishes an association between the function identifier of each intermediate code and the memory area mapped to the corresponding machine code, so as to call and execute from multiple memory areas based on the function identifier in the instruction packet subsequently sent by the instruction executor.

[0136] In some embodiments, before the instruction provider constructs the instruction package, the task sending module further includes: obtaining an access token for the task function to be executed from an authentication center, and encapsulating the access token together with the instruction package; the access token includes a token validity period and an audience field; the field value of the audience field points to a set of executor identifiers that can call the task function to be executed; After receiving the instruction packet, the task execution module further includes: verifying whether the access token in the instruction packet is within its validity period, and verifying whether the self-identifier of the instruction executor is within the range of field values ​​of the audience field; if both verifications pass, the intermediate code in the instruction packet is locally compiled into machine code supported by the instruction executor.

[0137] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0138] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0139] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 5 As shown, the electronic device 500 includes at least one processor 501, a memory 502, and a bus 503. At least one processor 501 is electrically connected to the memory 502. The memory 502 is configured to store at least one computer-executable instruction, and the processor 501 is configured to execute the at least one computer-executable instruction to perform the steps of any task processing method provided in any embodiment or optional implementation of this application.

[0140] Furthermore, the processor 501 can be an FPGA (Field-Programmable Gate Array) or other devices with logic processing capabilities, such as an MCU (Microcontroller Unit) or a CPU (Central Processing Unit).

[0141] This application also provides another readable storage medium storing a computer program that, when executed by a processor, implements the steps of any task processing method provided in any embodiment or optional implementation of this application.

[0142] The readable storage media provided in this application include, but are not limited to, any type of disk (including floppy disk, hard disk, optical disk, CD-ROM, and magneto-optical disk), ROM (Read-Only Memory), RAM (Random Access Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, magnetic cards, or optical cards. In other words, readable storage media include any medium by which a device (e.g., a computer) stores or transmits information in a readable form.

[0143] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0144] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A task processing method characterized by, The method comprises: The instruction provider compiles the task function source code to be executed into intermediate code, which is independent of hardware architecture and memory address; The instruction provider determines configuration information required for execution of the task function, and obtains an access control policy when the task function is executed, and constructs an instruction package based on the intermediate code, the configuration information, and the access control policy, and sends the instruction package to the instruction execution side; wherein the instruction provider and the instruction execution side run in different runtime environments isolated from each other; The instruction execution side locally compiles the intermediate code in the instruction package into machine code supported by the instruction execution side after receiving the instruction package, maps the machine code to a memory area readable and executable locally in the instruction execution side based on the configuration information, and executes the machine code in the memory area based on the configuration information and the access control policy to execute the task function, and returns the execution result of the task function to the instruction provider.

2. The method of claim 1, wherein, The instruction package is sent to the instruction execution side, comprising: In the case that the instruction execution side and the instruction provider belong to different processes of the same device, the instruction package is transmitted to the instruction execution side through a local inter-process communication channel; In the case that the instruction execution side and the instruction provider belong to different devices, the instruction package is transmitted to the instruction execution side through a Socket network connection between the instruction execution side and the instruction provider.

3. The method of claim 1, wherein, The task function source code to be executed is compiled into intermediate code, comprising: Based on the compilation tag of the task function source code, the compilation mode of the task function source code is determined; The task function source code is compiled using the compilation mode to generate an intermediate representation independent of hardware architecture; The intermediate representation is converted into a binary data format and encapsulated as intermediate code containing an execution entry identifier.

4. The method according to claim 1 or 3, characterized in that, Mapping the machine code to a memory area readable and executable locally in the instruction execution side based on the configuration information, comprising: Based on the code memory requirement information in the configuration information, a memory area is applied to the operating system of the instruction execution side, and the access permission of the memory area is set to be readable and executable; The machine code is written into the memory area.

5. The method of claim 4, wherein, Executing the machine code in the memory area based on the configuration information and the access control policy to execute the task function, comprising: Based on the function execution entry information in the configuration information, the entry address of the task function in the memory area is determined; The entry address is converted into a function pointer, and the function pointer is called to start execution of the task function; During execution of the task function, the running behavior of the task function is monitored in real time through the access control policy, and the execution of the task function is terminated when abnormal access behavior is detected.

6. The method of claim 1, wherein, The instruction package is sent to the instruction execution side, comprising: In a case where the task function corresponds to multiple executable candidate executors, a candidate executor is selected as the instruction executor from the multiple candidate executors based on running state information and at least one setting information of each candidate executor, and the instruction package is sent to the instruction executor; The setting information at least includes a preset load balancing strategy and a near routing strategy based on a network topology; the multiple candidate executors represent different processes in a same device end, or the multiple candidate executors represent multiple different device ends interconnected in a network.

7. The method of claim 1, wherein, The machine code corresponds to intermediate code having a unique function identifier; the instruction executor reserves the memory region within a preset time window for the machine code that has been mapped to the memory region, and releases the memory region in a case where the preset time window expires; The instruction package is constructed based on the intermediate code, the configuration information, and the access control strategy, including: The unique function identifier of the intermediate code is acquired; If there is no sending record of sending the intermediate code corresponding to the function identifier to the instruction executor within the preset time window before the current time, the function identifier, the intermediate code, the configuration information, and the access control strategy are encapsulated to generate the instruction package; Otherwise, the function identifier, the configuration information, and the access control strategy are encapsulated to generate the instruction package; the instruction package does not include the intermediate code.

8. The method of claim 7, wherein, After the instruction executor receives the instruction package, the method further includes: It is queried whether there is a target memory region matching the function identifier in the instruction package in each memory region reserved locally by the instruction executor; If there is, the machine code is executed in the target memory region based on the configuration information and the access control strategy to execute the task function; If there is not, the intermediate code in the instruction package is locally compiled into machine code supported by the instruction executor in a case where the instruction package includes the intermediate code, otherwise, instruction identifier not found indication information is returned to the instruction sender to request sending of the intermediate code corresponding to the function identifier in the instruction package.

9. The method of claim 1, wherein, The instruction package is sent to the instruction executor, including: multiple instruction packages encapsulated for each task function to be executed are aggregated into a batch transmission unit, and the batch transmission unit is sent to the instruction executor through a single communication connection; After the instruction executor receives the batch transmission unit, each intermediate code included in the batch transmission unit is locally compiled, and the machine code obtained by the compilation is mapped to a readable and executable memory region applied for the machine code, and an association relationship between the function identifier of each intermediate code and the memory region to which the machine code corresponding to the intermediate code is mapped is established, so as to call and execute from multiple memory regions based on the function identifier in the instruction package sent subsequently by the instruction executor.

10. The method of claim 1, wherein The instruction provider, before constructing the instruction package, the method further comprises: obtaining an access token for the to-be-executed task function from an authentication center, and encapsulating the access token into the instruction package; the access token comprises a token validity period and an audience field; a field value of the audience field points to a set of identifiers of execution parties that can call the to-be-executed task function; The instruction execution party, after receiving the instruction package, the method further comprises: verifying whether the access token in the instruction package is within the validity period, and verifying whether the identifier of the instruction execution party itself is within the field value range of the audience field; in the case that both verifications pass, locally compiling the intermediate code in the instruction package into machine code supported by the instruction execution party.

11. A task processing apparatus characterized by comprising: The apparatus comprises: A task sending module is configured to instruct a provider to compile to-be-executed task function source code into intermediate code, which is independent of hardware architecture and memory address; and to determine configuration information required for execution of the task function, and to obtain an access control policy when the task function is executed, and to construct an instruction package based on the intermediate code, the configuration information, and the access control policy, and to send the instruction package to an instruction execution party; wherein the instruction provider and the instruction execution party run in different runtime environments isolated from each other; A task execution module is configured to instruct the instruction execution party, after receiving the instruction package, to map the machine code to a memory area readable and executable locally based on the configuration information, and to execute the machine code in the memory area based on the configuration information and the access control policy to execute the task function, and to return an execution result of the task function to the instruction provider.

12. An electronic device, comprising: Comprise: A memory and a processor; The memory is configured to store a computer program; The processor is configured to call the computer program to implement the method in any one of claims 1-10.

13. A readable storage medium, having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method in any one of claims 1-10.

Images