Automated integration method of heterogeneous function libraries, computing device and system thereof

Abstract

Provided are an automatic integration method of heterogeneous function libraries, a computing device, and a system thereof. The provided method comprises: obtaining source code of a library function; generating dynamic library interface adaptation code according to the source code of the library function, wherein the dynamic library interface adaptation code comprises a dynamic library interface, library function interface conversion code, and code for calling the library function; wherein the library function interface conversion code is used to convert dynamic library parameters passed by the dynamic library interface into library function parameters required for calling the library function; compiling and building the source code and the dynamic library interface adaptation code to generate a dynamic library encapsulating the library function; and loading the dynamic library and using the library function to respond to a calling request for the library function.

Description

Technical Field

[0001] This application belongs to the field of software, and specifically relates to an automated integration method for heterogeneous function libraries, and its computing devices and systems. Background Technology

[0002] In applications such as underwater acoustic processing, various underwater acoustic processing algorithms are used. These algorithms are implemented as multiple function libraries. As the algorithms or their implementations evolve, the function libraries are updated accordingly. Some applications also involve testing or comparing the merits of various algorithms, thus requiring frequent replacement with new function libraries.

[0003] Different function libraries may have different function signatures (function declarations), such as different function names, input parameters, and / or output parameters. The number and / or types of parameters required by the functions may also differ (this is called heterogeneous function libraries). Furthermore, due to division of labor or software engineering reasons, the developers of function libraries are often different from the users, and each uses different runtime environments. Therefore, after a function library is updated, when using it in an application system, the new function library needs to be imported into the application system, the corresponding code needs to be readjusted according to the new function library's function signature, and the modified code needs to be compiled so that the function library can be called or used in the application system. When function libraries are frequently updated, these operations result in wasted time and resources and are prone to introducing errors.

[0004] For example, in the development of underwater acoustic spectrum analysis algorithms, the algorithm is typically designed first using scripting languages ​​such as MATLAB and R. After accuracy verification, the algorithm implemented in the scripting language is translated into a C language function library. This conversion process from scripting language to C language function library can be automated by software tools, which is part of existing technology. The C language function library is then passed to the application system. Application system developers write adaptation code based on the function signatures of the received library. However, when performing tasks such as efficiency optimization, it is necessary to constantly switch between various libraries used in the application system to compare which library's algorithm is more efficient and consumes less resources. This process consumes a significant amount of time for application system developers, leading to a decrease in development efficiency.

[0005] Figure 1 A schematic diagram of the system architecture of an application system that uses function libraries in existing technologies is shown.

[0006] Figure 1In this context, the application system includes, for example, applications and function libraries, each developed by different people. A function library consists of multiple library functions (denoted as library function 1, library function 2, and library function 3). Each library function includes a function declaration (function signature) and a function body. These multiple library functions can be different implementations, versions, or implementations of the same algorithm. Therefore, the function declarations of the various library functions can be the same or different.

[0007] Library developers deliver the source code of their libraries, for example, implemented in C, to application developers. Applications use the functionality provided by these library functions by calling them. Since the function declarations of different library functions may differ, application developers need to write adaptation code based on the function declarations of the specific library functions they are using. This adaptation code provides the necessary parameters to the called library functions, ensuring that the number and types of these parameters match the function declarations. Finally, the application is compiled, built, and run.

[0008] In the process described above, each library update may require corresponding source code-level adjustments to the application, as well as compilation, building, and deployment of the updated application in the runtime environment. This introduces additional open source requirements and may also introduce errors. Summary of the Invention

[0009] The aim is to address the time-consuming and error-prone problem caused by repeatedly developing adaptation code, compiling, and building application software when using heterogeneous function libraries in application systems.

[0010] According to embodiments of this application, one or more of the aforementioned technical problems are solved through a two-stage technical improvement. In the first stage, heterogeneous library functions are automatically encapsulated into independent function libraries that can be dynamically loaded by the runtime environment and replaced at any time during runtime. In the second stage, the runtime environment supports user-specified library functions and provides a unified interface for user applications to call library functions. This allows applications to select / change the library functions to use during runtime and call multiple library functions in a unified (or identical) manner without modifying the application source code. The runtime environment "hot-loads" the corresponding function library based on the user-selected library function and completes the call to the library function. During this process, the source code of the application and the runtime environment does not need to be modified, nor does it need to be rebuilt and / or restarted.

[0011] According to a first aspect of this application, an automated integration method for a first heterogeneous library function according to the first aspect of this application is provided, comprising: obtaining the source code of the library function; generating dynamic library interface adaptation code based on the source code of the library function, wherein the dynamic library interface adaptation code includes a dynamic library interface, library function interface conversion code, and code for calling the library function; wherein the library function interface conversion code is used to convert dynamic library parameters passed by the dynamic library interface into library function parameters required for calling the library function; compiling and constructing the source code and the dynamic library interface adaptation code to generate a dynamic library encapsulating the library function; loading the dynamic library, and using the library function to respond to a call request for the library function.

[0012] According to the first aspect of the automated integration method for heterogeneous library functions, a second aspect of the automated integration method for heterogeneous library functions is provided, further comprising: in response to receiving a call request for the library function from the client, extracting one or more data fields from the call request, each data field corresponding to one of the parameters required to call the library function, each data field recording the type and value of its corresponding parameter; and passing the parameters extracted from the one or more data fields to the dynamic library to call the library function encapsulated by the dynamic library through the dynamic library.

[0013] According to the second method for automated integration of heterogeneous library functions according to the first aspect of this application, a third method for automated integration of heterogeneous library functions according to the first aspect of this application is provided, which further includes: obtaining the execution result of calling the library function from the dynamic library and passing it to the client as a response to the call request.

[0014] According to the second or third method for automated integration of heterogeneous library functions according to the first aspect of this application, a fourth method for automated integration of heterogeneous library functions according to the first aspect of this application is provided, wherein for each parameter extracted from the one or more data domains, the extracted parameter type is erased, one or more parameters with the erased type are combined into a variable-length parameter, and the variable-length parameter is passed to the dynamic library.

[0015] According to the fourth method for automated integration of heterogeneous library functions in the first aspect of this application, a fifth method for automated integration of heterogeneous library functions in the first aspect of this application is provided, wherein the data field further includes a target field, the target field corresponding to a library function; and the library function applicable to the parameters carried by the data field is determined according to the value of the target field.

[0016] According to the fifth method for automated integration of heterogeneous library functions in the first aspect of this application, a sixth method for automated integration of heterogeneous library functions in the first aspect of this application is provided, wherein for different call requests to different library functions from the client, regardless of whether the number of parameters of the call library functions extracted from the different call requests is the same or whether the types of the parameters extracted from the different call requests correspond to the same, the generated parameters passed to the same or different dynamic libraries have the same form.

[0017] According to the sixth method for automated integration of heterogeneous library functions in the first aspect of this application, a seventh method for automated integration of heterogeneous library functions according to the first aspect of this application is provided, wherein the generated parameters passed to the same or different dynamic libraries are variable-length parameters, and the types of each element carried by the variable-length parameters are erased, or each element has the same specified type; or the generated parameters passed to the same or different dynamic libraries are a specified number of parameters, and the types of the specified number of parameters are erased, or each of the specified number of parameters has the same specified type.

[0018] According to the seventh method for automated integration of heterogeneous library functions in the first aspect of this application, an eighth method for automated integration of heterogeneous library functions in the first aspect of this application is provided. The library function interface conversion code is used to extract parameters passed to a dynamic library as dynamic library parameters, obtain the types of each parameter required to call the library function based on the function signature of the library function, perform type conversion on the dynamic library parameters, and sequentially convert each dynamic library parameter to the parameter type obtained from the function signature of the library function. The type conversion results of each dynamic library parameter correspond one-to-one with the types of each parameter required to call the library function in sequence. The code for calling the library function is used to provide the converted dynamic library parameters to the library function.

[0019] According to the eighth method for automated integration of heterogeneous library functions in the first aspect of this application, a ninth method for automated integration of heterogeneous library functions in the first aspect of this application is provided, wherein the parameters passed to different dynamic libraries have the same form; and when the interface parameters required by the library functions encapsulated by the different dynamic libraries are different, the parameters required for calling the library functions generated by the library function interface conversion code from the dynamic library parameters are different.

[0020] According to the ninth method for automated integration of heterogeneous library functions in the first aspect of this application, a tenth method for automated integration of heterogeneous library functions according to the first aspect of this application is provided, wherein in the call request of the library function, each data field is separated by a byte with a specified value; when the type and value of the parameter recorded in the data field are to contain a byte with the specified value, two consecutive bytes with the specified value are used to represent a single byte with the specified value.

[0021] According to the first heterogeneous library function automatic integration method of the first aspect of this application, an eleventh heterogeneous library function automatic integration method according to the first aspect of this application is provided, wherein the generated dynamic library is added to a specified location in the file system so that the dynamic library can be loaded and used; one or more dynamic libraries in the file system are loaded into memory to become memory dynamic libraries; and one of the memory dynamic libraries is selected as the current dynamic library in response to a call request for the library function.

[0022] The automated integration method for heterogeneous library functions according to the eleventh heterogeneous library function of the first aspect of this application provides an automated integration method for heterogeneous library functions according to the first aspect of this application, which further includes: unloading one or more memory dynamic libraries, wherein the memory dynamic libraries to be unloaded are selected according to a least recently used strategy or a first-in-first-out strategy.

[0023] According to the first aspect of the first method for automated integration of heterogeneous library functions, an automated integration method for thirteenth heterogeneous library functions according to the first aspect of the present application is provided, wherein the dynamic library creation unit performs the step of obtaining the source code of the library function, the step of generating dynamic library interface adapter code based on the source code of the library function; and the step of compiling and building the source code and the dynamic library interface adapter code to generate a dynamic library encapsulating the library function; and the runtime environment performs the step of loading the dynamic library.

[0024] According to a second aspect of this application, an automated integration system for a first heterogeneous library function according to the second aspect of this application is provided, comprising a dynamic library creation unit and a runtime environment; the dynamic library creation unit acquires the source code of the library function; generates dynamic library interface adaptation code based on the source code of the library function, wherein the dynamic library interface adaptation code includes a dynamic library interface, library function interface conversion code, and code for calling the library function; wherein the library function interface conversion code is used to convert the dynamic library parameters passed by the dynamic library interface into library function parameters required for calling the library function; compiles and constructs the source code and the dynamic library interface adaptation code to generate a dynamic library encapsulating the library function; the runtime environment loads the dynamic library and uses the library function to respond to a call request for the library function.

[0025] An automated integration system for a first heterogeneous library function according to a second aspect of this application is provided, wherein the runtime environment, in response to receiving a call request for the library function from the client, extracts one or more data fields from the call request, each data field corresponding to one of the parameters required to call the library function, and each data field recording the type and value of its corresponding parameter; the parameters extracted from the one or more data fields are passed to the dynamic library to call the library function encapsulated by the dynamic library.

[0026] An automated integration system for a second heterogeneous library function according to a second aspect of this application is provided, along with an automated integration system for a third heterogeneous library function according to a second aspect of this application, further comprising a client; the client generating a call request for the library function including one or more data fields based on one or more parameters required to call the library function; sending the call request for the library function to the runtime environment; and receiving the execution result of the library function provided by the runtime environment.

[0027] According to a third aspect of this application, a first computer device according to the third aspect of this application is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement one of the automated integration methods for the first to thirteenth heterogeneous library functions according to the first aspect of this application. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0029] Figure 1 A schematic diagram of the system architecture of an application system that uses function libraries in existing technologies is shown.

[0030] Figure 2 A system architecture block diagram of an automatic integration system for heterogeneous function libraries according to an embodiment of this application is shown.

[0031] Figure 3 A flowchart illustrating the process of creating a dynamic library according to an embodiment of this application is provided.

[0032] Figure 4 A flowchart illustrating the generation of a dynamic library from a generated build configuration file according to an embodiment of this application is shown.

[0033] Figure 5AA flowchart illustrating a client calling an integrated library function according to an embodiment of this application is shown.

[0034] Figure 5B This diagram illustrates the network data packets that carry the call requests for library functions.

[0035] Figure 6 A flowchart illustrating client-side calls to library functions according to an embodiment of this application is shown. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0037] Figure 2 A system architecture block diagram of an automatic integration system for heterogeneous function libraries according to an embodiment of this application is shown.

[0038] The heterogeneous function library automatic integration system according to embodiments of this application includes a client (user application), a runtime environment, and function libraries.

[0039] User applications interact with the runtime environment in a client-server model. The user application, acting as a client, requests library functions from the server in a uniform format (interface or data packet format) and receives the results from the server. Even if the function declaration of the called library function changes (due to different usage, required parameters of different types or numbers, and / or the use of a different function name), the client can remain unaware of or adapt to this change, and continue to call the specified library function through the server in a single direction.

[0040] The runtime environment, acting as a server, receives call requests for library functions from applications, parses one or more parameters from the call requests, and loads or invokes the dynamic library containing the called library function. Different versions of library functions are encapsulated as different dynamic libraries. As one implementation, different dynamic libraries export (present) a unified interface to the runtime environment, allowing the runtime environment to call the interface provided by the dynamic library in a consistent manner. For example, the number and types of parameters required by the interface provided by the dynamic library correspond to the number and types of parameters provided in the client's call request. The runtime environment then passes all the parameters provided in the client's call request to the interface provided by the dynamic library.

[0041] Each dynamic library includes an interface (dynamic library interface), library function interface conversion code, the call to the library function, and the library function itself. For example, Figure 2In this context, the runtime environment contains multiple dynamic libraries (dynamic library 1, dynamic library 2, and dynamic library 3). The runtime environment is, for example, a computer or server, and the dynamic libraries are stored in a database or the runtime environment's file system. Each dynamic library has, for example, a unified dynamic library interface, but because the library functions encapsulated by each dynamic library are different, each dynamic library has its own library function interface conversion code and code for calling the library functions. For example, dynamic library 1 encapsulates library function 1 and has library function interface conversion code 1 and code for calling library function 1. Similarly, dynamic library 2 encapsulates library function 2 and has library function interface conversion code 2 and code for calling library function 2; dynamic library 3 encapsulates library function 3 and has library function interface conversion code 3 and code for calling library function 3.

[0042] Library functions consist of a function declaration (also called a function signature) and a function body. Library function 1 includes function declaration 1 and function body 1, library function 2 includes function declaration 2 and function body 2, and library function 3 includes function declaration 3 and function body 3. Since function declaration 1, function declaration 2, and function declaration 3 may differ from each other, the library function interface conversion code and the code that calls the library functions will also differ accordingly in each dynamic library.

[0043] In a dynamic library, the code that calls the library function passes the required parameters to the encapsulated library function based on its declaration and then invokes the function. The library function interface conversion code, on the other hand, converts each of the one or more parameters received from the dynamic library interface in a uniform form into the form required by the encapsulated library function. Optionally, the library function interface conversion code also distinguishes between the input and output parameters of the encapsulated library function, using the input parameters to call the library function and the output interface to receive the processing results of the library function.

[0044] According to embodiments of this application, a dynamic library creation unit is also included, used to construct a corresponding dynamic library based on the newly delivered library functions and import it into the runtime environment. The creation of the dynamic library and the client's call to the dynamic library occur at different times, therefore... Figure 2 The dynamic library creation unit is not shown. The dynamic library creation unit is a computer or server. The dynamic library creation unit may be the same as or a different computer or server as the runtime environment.

[0045] The dynamic library creation unit is implemented, for example, by software. When a new library function is delivered, its source code is also delivered. Based on the function declaration of the new library function, the dynamic library creation unit obtains one or more parameters (and their data types) required to call the function. Then, based on the differences between the parameters provided by the unified dynamic library interface (ULI) of each dynamic library and the parameters described in the function declaration of the new library function, it generates conversion code for each parameter in the function declaration, converting the parameter types of the ULI to the parameter types specified in the function declaration. When there are multiple parameters, the parameters transmitted by the ULI are mapped one-to-one to the parameters in the function declaration in a specified order (e.g., from front to back or from back to front). Therefore, the number of parameters provided by the ULI is greater than or equal to the number of parameters in the function declaration. The code generated by the dynamic library creation unit also includes code for calling the library function with the converted parameters, and optionally, code for receiving the execution result of the library function.

[0046] For example, the parameters transmitted by the dynamic library interface include T1, T2, T3...Tn, each of which may not have a type, be typed parameter, or default data type; while the parameters described in the function declaration of the library function include int a, float b, char c. The dynamic library creation unit, based on the three parameters required by the library function obtained from the function declaration, with data types int (integer), float (floating-point), and char (character), selects the first three parameters (T1, T2, and T3) from the function transmitted by the dynamic library interface, generates type conversion code for each of these three parameters to obtain three parameters suitable for providing to the library function, and generates code to call the library function.

[0047] The dynamic library creation unit also compiles the generated code and corresponding library functions to construct a dynamic library corresponding to the library function. According to embodiments of this application, for heterogeneous library functions, the dynamic library interface of the constructed dynamic library is the same. For example, based on design requirements or experience, the number of parameters described in the function declarations of various library functions may be less than a certain value (e.g., 100). Therefore, 100 parameters are provided in a unified dynamic library interface, so that this number of parameters meets the needs of each library function.

[0048] According to another embodiment of this application, in order to ensure that when the runtime environment calls the dynamic library interface, the corresponding calling code in the runtime environment does not need to be modified for multiple dynamic libraries encapsulating different library functions, the input and output parameters passed at the "coupling" (interface) between the dynamic library and the runtime environment follow a unified approach. The dynamic library interface used employs variable-length formal parameters and parameter types that can be type-erased. Type erasure refers to removing the type information of parameters, making the types of different parameters appear the same or indistinguishable. Variable-length formal parameters can pass any number of parameters, thereby adapting to the different number of parameters required by different library functions. Type erasure and variable-length parameters support arbitrary combinations of different types / numbers of formal parameters in different library functions.

[0049] Therefore, according to the embodiments of this application, no other code for compatibility or type conversion needs to be provided in the runtime environment outside the generated dynamic library, and the added code exists only in the dynamic library, so that when updating library functions, only the dynamic library needs to be compiled and built, without recompiling / building the entire runtime environment.

[0050] Optionally, the dynamic library creation unit can also add the built dynamic library to the runtime environment. For example, the dynamic library can be added to a specified directory in the file system or a specified location in the database, causing the runtime environment to scan the specified directory or database to load the newly generated dynamic library.

[0051] The generation of dynamic libraries belongs to the first stage of technology mentioned above.

[0052] The runtime environment includes a dynamic library management unit and a library function proxy unit. The dynamic library management unit loads or releases dynamic libraries. For example, it periodically scans the instruction directory or database of the file system to identify new dynamic libraries and load them into the runtime environment. The library function proxy unit listens for library function call requests from clients on the network, parses one or more parameters from the request, and optionally the library function to be called, calls the corresponding dynamic library, and transmits the parameters from the call request to the called dynamic library. Optionally, the library function call proxy also returns the library function call result provided by the dynamic library to the client. Still optionally, the library function call proxy also receives the client's selection of a library function to determine the dynamic library corresponding to the selected function.

[0053] Handling library function call requests from clients belongs to the second phase of technology.

[0054] Continue reading Figure 2When a client wants to call a specified library function, it packages the call request into a network data packet and sends it to the server (runtime environment). The call request carries a specified number of parameters (e.g., 100). The client knows the function declaration of the library function to be called. Therefore, even if the library function to be called only requires 3 parameters, the client still packages a specified number of parameters (e.g., 100) into the library function call request, of which only the first 3 parameters are set with meaningful values ​​(to be passed to the library function), while the other parameters can be filled with random numbers or specified values.

[0055] The library function call proxy unit receives a call request from the client and calls the dynamic library corresponding to the library function to be called, using, for example, all the parameters in the call request. The interfaces of each dynamic library are uniform and also include, for example, a specified number (e.g., 100) of parameters. Because the parameters of the library function call request provided by the client and the dynamic library interface are formally identical, the library function proxy can call the dynamic library interface based on the parameters provided in the call request even if the client calls different library functions. Optionally or further, the types of the parameters in the call request provided by the client correspond to the types of the parameters in the dynamic library interface to avoid parameter type inconsistency errors when calling the dynamic library. Again, optionally, the parameters of the dynamic library interface are untyped, type-erased, or of a default type, so that the dynamic library interface can accept parameters of various types provided in the call request.

[0056] In response to a dynamic library interface being invoked, the dynamic library interface conversion code is executed, converting the specified number and location of parameters (e.g., the first three parameters) in the dynamic library interface into the data types required to call the library function. Then, the library function calling code is executed to invoke the library function, passing the converted parameters to the library function, thus completing the call to the library function.

[0057] Optionally, the library function proxy unit also packages the return parameters of the library functions provided by the dynamic library into network packets and provides them to the client. The network packets returned by the library function proxy unit to the client also have a specified format, so that the client can receive various return values ​​from different library functions in a uniform way.

[0058] The client and the library function proxy unit communicate or exchange information through methods such as sockets, shared memory, and pipes. The communication protocol used between the client and the library function proxy is a multi-protocol where both parties are aware of the data packet format. Within this protocol, the parameters for calling the library function can be explicitly defined or hidden. When the library function's parameters are explicitly defined, the runtime environment extracts each parameter from the data packet and passes it to the dynamic library interface after type erasure. When the library function's parameters are hidden, the runtime environment can pass the entire data packet or a specified portion as a variable-length parameter to the dynamic library interface.

[0059] Optionally, to inform client applications which library functions have been successfully added to the system, the library function proxy also sends a list of loaded library functions to the client, allowing the client to select its own library functions from a variety of options. Optionally, the library function list also includes library function source information, allowing the client to know which library functions were provided by itself or by a specified provider.

[0060] Figure 3 A flowchart illustrating the process of creating a dynamic library according to an embodiment of this application is provided.

[0061] When a library function is updated, a dynamic library that encapsulates that function is generated based on the new function. The generation of this dynamic library can be triggered in response to an update to the library function. For example, when code for a new library function is submitted... Figure 3 The processing flow shown is executed.

[0062] Obtain the source code of the updated library function (310), add dynamic library interface adaptation code, and convert one or more dynamic library parameters passed to the dynamic library interface when calling the dynamic library into the library function parameters required for calling the library function (320). The added dynamic library interface adaptation code includes, for example, the dynamic library interface, library function interface conversion code, and code for calling the updated library function. The dynamic library interface includes the name of the dynamic library interface and the formal parameters used. For example, the formal parameters used by the dynamic library interface include, for example, a specified number of parameters or variable-length parameters. According to the embodiments of this application, when generating the dynamic library interface adaptation code, for dynamic libraries that encapsulate different library functions, the formal parameters of their dynamic library interfaces are the same or uniform. The parameter types of each dynamic interface are also the same or uniform, for example, they are all erased types, or they are all specified or default types.

[0063] The generated library function interface adapter code is used to perform operations such as steps 322-332. To generate the library function interface conversion code, the number of dynamic library parameters passed by the dynamic library interface is first obtained (322). Obtaining the number of dynamic library parameters is optional; its purpose is to determine early on whether the number of parameters passed from the dynamic library interface matches the number of parameters required by the library function. In the case of variable-length parameters passed by the dynamic library interface, code needs to be added to identify the length (number of parameters) of the passed variable-length parameters. In the case of a specified number of parameters passed by the dynamic library interface, the number of parameters can be identified from the displayed parameter list of the dynamic library interface. The various dynamic library parameters used by the calling dynamic library are extracted (324). Since parameter types are erased, the types of each dynamic library parameter cannot be obtained from the dynamic library interface; instead, the types of each dynamic library parameter are determined based on the types of library function parameters required by the library function.

[0064] Based on the function declaration of the library function, the types of each library function parameter required to call the library function are obtained (326). Since the interface forms of each library function can be different (e.g., with different numbers of parameters), it is necessary to parse the library function interface form. For example, the function declaration of the library function is obtained from the library function source code, and the function name, number of parameters, and types of each parameter are identified. Optionally, the order of the parameters in the parameter list of the function declaration is also identified. A one-to-one mapping is established between each dynamic library parameter and each library function parameter. For example, the first parameter of the dynamic library parameter is mapped to the first parameter of the library function parameter, the second parameter of the dynamic library parameter is mapped to the second parameter of the library function parameter, and so on. Based on the types of each library function parameter obtained from the function declaration of the library function, each dynamic library parameter whose type has been erased is sequentially converted to the type of its corresponding library function parameter (328). Optionally, for parameters used to hold the output of the library function, code for allocating memory space for them is also generated.

[0065] For example, the parameter list of the dynamic library interface is “T …args”, where T represents the default type or erased type, and “…args” represents variable-length parameters. The number of dynamic library parameters passed from the dynamic library interface at runtime can be obtained by identifying the number of elements included in args. The function declaration of the library function is, for example, “foo(int a, char b, float c, double d)”, which includes 4 parameters (a, b, c and d), and each parameter has a definite type. The first element of the variable-length parameter args (denoted as args[0]) is converted to int type (integer) and passed to the library function as parameter a. The second element of the variable-length parameter args (denoted as args[1]) is converted to char type (character) and passed to the library function as parameter b, and so on.

[0066] As another example, the parameter list of the dynamic library interface is "arg1, arg2, arg3, arg4, arg5", while the function declaration of the library function is, for example, "foo(int a, char b, float c, double d)". In the generated code that converts each dynamic library parameter to its corresponding library function parameter type, arg1 is converted to int, arg2 to char, arg3 to float, arg4 to arg5, while the parameter arg5 in the dynamic library interface is not used. Based on the number of parameters used in the library function's function declaration, it is determined which parameters in the dynamic library interface are used and which are optional.

[0067] Return to view Figure 3 Based on the function declaration of the library function, generate the code to call the library function, and provide the dynamic library parameters, which have been converted to different types, as library function parameters (330).

[0068] Library functions can have return values, or the result of their execution can be passed through one or more library function parameters in the function declaration (for simplicity, the return value or execution result of a library function is collectively referred to as the processing result). When it is necessary to obtain the processing result of a library function, the generated code is also used to obtain the processing result of the library function and convert the processing result into the output parameters of the dynamic library to be passed to the runtime environment.

[0069] Compile the library functions and the dynamic library interface adapter code generated in step 320, and generate a dynamic library (340) that encapsulates the library functions.

[0070] Optionally, the generated dynamic library is also added to the runtime environment (see also...) Figure 2 (The operating environment).

[0071] According to an embodiment of this application, optionally, a configuration file for compilation / building is also generated before compiling the library functions.

[0072] To meet, for example, the cross-platform requirements of the generated dynamic library, the target system architecture and / or operating system specified by the user is obtained, and a corresponding build configuration file is generated based on the user-selected target architecture / operating system. During the compilation / build process, this build configuration file is used to compile the dynamic library interface adaptation code and library function code to generate the target dynamic library.

[0073] Figure 4 A flowchart illustrating the generation of a dynamic library from a generated build configuration file according to an embodiment of this application is shown.

[0074] When compiling and building a dynamic library, the build configuration file is read, displaying one or more available configuration options to the user (e.g., the target system architecture / operating system to run the dynamic library). The configuration selected by the user is retrieved. Optionally, the default configuration is used without requiring user selection. In response to the determined configuration (based on user selection or the default configuration), a new configuration file is generated in the build directory. The build system then rereads this new build configuration file and begins the compilation and build process.

[0075] Optionally, to ensure the generated build process is "reentrant" (i.e., if compilation fails, the user can re-execute the build process without breaking the original configuration), a copy of the build configuration file is first made during the build process. If the user needs to modify the build configuration file for this build process, it is done on the copy without changing the original build configuration file, thus ensuring that the build process is reentrant.

[0076] If there are multiple source code files, each source code file is compiled according to the obtained build configuration. The compilation results of all source code files are then used to build the target dynamic library.

[0077] Figure 5A A flowchart illustrating a client calling an integrated library function according to an embodiment of this application is shown.

[0078] In response to a client's call to a library function, the runtime environment selects and loads the dynamic library (510) corresponding to the library function the client wants to call. This step is optional; the runtime environment (see also...) Figure 2 A single dynamic library can be loaded in the runtime environment, so that all calls from clients correspond to calls to that dynamic library. Once loaded, the dynamic library is maintained in the runtime environment, so it does not need to be reloaded for subsequent calls. Alternatively, multiple dynamic libraries can be loaded in the runtime environment, all of which can respond to client calls. The call request may or may not specify a dynamic library. Alternatively, the dynamic library can be loaded based on the one specified in the call request.

[0079] The client provides the runtime environment with a call request in the form of a network packet. The network packet includes one or more data fields. Each data field is extracted from the packet (520). The data fields carry the parameters required to call the library function.

[0080] Figure 5B This diagram illustrates the network data packets that carry the call requests for library functions.

[0081] The request includes one or more network packets. Figure 5BThe data packet includes multiple data fields, each containing a data type field and a data value. The sizes of different data fields are variable, thus distinguishing the boundaries of adjacent data fields using specified markers. A marker is, for example, a byte with a specified value (e.g., the decimal number "124"). Within a data field, a region of specified position and length describes the data type (e.g., int, int[], int16, float, double, etc.), and the remaining portion is the data value, which has the type indicated by the data type field. According to embodiments of this application, the network data packet of a library function call request carries the data type of the parameters, enabling the runtime environment to distinguish between parameters and perform operations. Furthermore, in the parameters provided to the dynamic library interface by the network environment, the type is erased or converted to a default type, allowing parameters of different types to be passed to the dynamic library interface in a unified manner. This enables the runtime environment to call the dynamic library interface in a unified way based on the received library function call request, without needing to handle the differences in the library functions encapsulated by the dynamic library.

[0082] Optionally, when using bytes with specified values ​​as boundaries to distinguish data fields in a data packet, it is necessary to transmit the specified value as the data value. For this purpose, when the specified value (e.g., a single byte representing the decimal number 124) appears in the data packet that is not a boundary of a data field, a decimal number 124 is added before that byte to form two consecutive decimal numbers 124. These two consecutive decimal numbers 124 represent a single decimal number 124 (rather than representing a boundary marker for a data field). In the runtime environment, if a single decimal number 124 is received, it is recognized as the boundary between two data fields; if two consecutive decimal numbers 124 are received, it represents a byte of the decimal number 124 within the data value. Therefore, a single decimal number 124 will not appear in the data value portion of the data field; a single decimal number 124 will represent a boundary of the data field.

[0083] Optionally, in some cases, a single call request indicates the invocation of multiple library functions, which are then combined to achieve richer functionality, such as complex underwater acoustic signal processing. For this purpose, it is necessary to distinguish the correspondence between the multiple parameters carried in the call request and the multiple library functions. A target field of a specified length is added to the data field, where the value represents the library function or group of library functions corresponding to the parameters carried by that data field. Furthermore, there can be multiple data fields with the same target in the call request. The parameters carried by each of these data fields correspond one-to-one with the parameters required by the library function (or group of library functions) represented by the target, according to the order in which the data field appears in the data packet. Thus, it is possible to pass the parameters required by multiple library functions to the runtime environment in a single call request, without being limited by changes in the number of library function parameters.

[0084] As an example, Table 1 shows the parameters required for the DEMON_LOFAR spectrum calculation algorithm library. The DEMON_LOFAR library includes various algorithms, such as a three-stage bandpass filter, a three-stage low-pass filter, a three-stage high-pass filter, the DEMOM algorithm, and the LOFAR algorithm. These algorithms can be implemented by their respective library functions or groups of library functions. The spare parameters in Table 1 represent parameters reserved for future expansions or improvements to the algorithm library.

[0085] Table 1 identifies that the total number of parameters required by the DEMON_LOFAR spectrum calculation algorithm library is finite (e.g., 75, or less than 100), and the number of algorithm types it includes (corresponding to library functions or groups of library functions) is also finite (e.g., 14). This ensures that the data packet size carrying the call request is not excessively large, making it suitable for network transmission or for selecting an appropriate server-client interaction method. Furthermore, the size of the target field distinguishing the algorithm types can be determined (e.g., a 1-byte target field can be used to represent 14 algorithms).

[0086] Some dynamic library interfaces / function interfaces have a limited number of parameters that can be passed. Depending on the number of parameters required by the specific algorithm library, this can also help in choosing whether to use parameter list form or variable-length parameter form to pass parameters between the runtime environment and the dynamic library.

[0087] Table 1

[0088] Serial Number Parameter name Parameter type 1 Current second int 2 DEMON audio source data length int 3 DEMON audio source data double[] 4 LOFAR audio source data length int 5 LOFAR audio source data double[] 6 signal sampling rate int 7 Low-pass filter upper limit frequency 1 int 8 Low-pass filter upper limit frequency 2 int 9 Low-pass filter upper limit frequency 3 int 10 Low-pass filter order 1 int 11 Low-pass filter order 2 int 12 Low-pass filter order 3 int 13 High-pass filter lower cutoff frequency 1 int 14 High-pass filter lower cutoff frequency 2 int 15 High-pass filter upper limit frequency 3 int 16 High-pass filter order 1 int 17 High-pass filter order 2 int 18 High-pass filter order 3 int 19 Bandpass filter lower cutoff frequency 1 int 20 upper limit frequency of bandpass filter 1 int 21 Bandpass filter lower cutoff frequency 2 int 22 upper limit frequency of bandpass filter 2 int 23 Bandpass filter lower cutoff frequency 3 int 24 Bandpass filter upper limit frequency 3 int 25 Bandpass filter order 1 int 26 Bandpass filter order 2 int 27 Bandpass filter order 3 int 28 DEMON Average Line Spectrum Extraction Frequency Threshold int 29 DEMON Average Line Spectrum Extraction Probability Threshold double 30 DEMON Average Line Spectrum Extraction Slope Threshold double 31 DEMON's average line spectrum extraction peak height threshold double 32 DEMON line spectrum extraction spectral width threshold int 33 LOFAR average line spectrum extraction frequency threshold int 34 LOFAR Average Line Spectrum Extraction Probability Threshold double 35 LOFAR average line spectrum extraction slope threshold double 36 LOFAR average line spectrum peak height extraction threshold double 37 LOFAR average line spectrum extraction spectral width threshold int 38 DEMON cumulative result amplitude double[] 39 DEMON's cumulative result amplitude length int 40 DEMON cumulative result frequency double[] 41 DEMON cumulative result frequency length int 42 DEMON instantaneous result amplitude double[] 43 DEMON instantaneous result amplitude length int 44 DEMON instantaneous result frequency double[] 45 DEMON instantaneous result frequency length int 46 DEMON's average line spectrum result amplitude double[] 47 DEMON's average line spectrum result amplitude length int 48 DEMON's average line spectrum results frequency double[] 49 DEMON's average line spectrum results: frequency length int 50 LOFAR cumulative result amplitude double[] 51 LOFAR cumulative result amplitude length int 52 LOFAR cumulative result frequency double[] 53 LOFAR cumulative result frequency length int 54 LOFAR peak cumulative result amplitude double[] 55 LOFAR peak cumulative result amplitude length int 56 LOFAR instantaneous result frequency double[] 57 LOFAR instantaneous result frequency length int 58 LOFAR average line spectrum amplitude double[] 59 LOFAR average line spectrum result amplitude length int 60 LOFAR average line spectrum results frequency double[] 61 LOFAR average line spectrum results frequency length int 62 Fourier transform points 1 int 63 Fourier transform points 2 int 64 Fourier transform points 3 int 65 Number of resampling points: 1 int 66 Number of resampling points 2 int 67 Number of resampling points: 3 int 68 Data segmentation flags int 69 Data segment length int 70 Number of data segments int 71 Alternate parameter 1 int 72 Alternate parameter 2 int 73 Alternate parameter 3 int 74 Alternate parameter 4 int 75 Alternate parameter 5 int

[0089] pass Figure 5B The network packet structure shown, even if the types / numbers of parameters in the library function call request change with library function updates, does not require modification to the runtime environment's code for receiving, parsing, and scheduling the dynamic library interface (through...). Figure 5A (The processing flow shown). Thus, without shutting down the runtime environment, the dynamic library can be loaded, and the newly loaded dynamic library can be used to respond to client call requests.

[0090] Alternatively, the runtime environment can manage dynamic libraries, including hierarchical loading strategies and dynamic replacement strategies for dynamic libraries.

[0091] To enable the replacement of dynamic libraries at any time, whether the runtime environment is running or shut down, a hierarchical loading strategy is adopted for dynamic libraries. This strategy is divided into three levels based on the storage hierarchy of the dynamic library: file system dynamic libraries, memory dynamic libraries, and current dynamic libraries. File system dynamic libraries are stored in directories within the file system; only dynamic libraries in these directories are eligible to be loaded into the runtime environment's memory for use. Memory dynamic libraries are those loaded into the runtime environment's memory; these can be selected at any time during runtime, and the memory dynamic libraries selected for use are called current dynamic libraries.

[0092] When you need to add a usable dynamic library to the runtime environment, you must first copy the dynamic library file generated after compilation and building to the specified file directory (making it a file system dynamic library). See also the runtime environment's dynamic library management unit (see also...). Figure 2 The system scans for dynamic libraries in the file system. File system dynamic libraries are those available to the runtime environment and can be queried by clients, allowing them to query and select specific dynamic libraries to load into the runtime environment's memory as in-memory dynamic libraries. Clients can send a request to specify a particular in-memory dynamic library as the current dynamic library; correspondingly, the runtime environment (dynamic library management unit) responds to the client's request by replacing the current dynamic library with the one selected by the client.

[0093] Alternatively, if there is only one dynamic library currently, the client's request to call a library function is provided to the dynamic library interface of the current dynamic library, thus eliminating the need to specify the dynamic library used in the call request. Alternatively, the client can specify the dynamic library used in the call request, and the dynamic library management unit, in response, replaces the current dynamic library in the runtime environment with the dynamic library specified by the client.

[0094] The runtime environment has limited resources, and therefore the number of in-memory dynamic libraries is also limited. Hierarchical loading and dynamic replacement strategies help reduce the resource overhead (computing and storage resources) of various dynamic libraries on the runtime environment. For example, before starting the runtime environment, the number of dynamic libraries that the in-memory dynamic libraries can hold can be set. When the capacity of the in-memory dynamic libraries reaches the upper limit that the runtime environment can hold, the dynamic libraries in the in-memory dynamic libraries will be replaced. First-in-first-out (FIFO) or least recently used (LRU) strategies are used to select dynamic libraries to be removed from the in-memory dynamic libraries. The LRU replacement strategy requires additional usage count work, which may cause some inefficiency, but it minimizes the system instability caused by replacing dynamic libraries.

[0095] Figure 6 A flowchart illustrating client-side calls to library functions according to an embodiment of this application is shown.

[0096] Operating environment (see also) Figure 2 This manages dynamic libraries that have encapsulated library functions. Clients access the runtime environment to use library functions and obtain the results of function calls from the runtime environment. The runtime environment and the client can be located on the same or different computers.

[0097] To invoke a library function, the client selects the library function to use (610). This selection is manifested, for example, by instructing the runtime environment to set a specified dynamic library as the current dynamic library. Step 610 is optional and need not be performed every time the client wants to invoke a library function. Optionally, the runtime environment may also provide the client with information on several available dynamic libraries to facilitate the client's selection of the desired dynamic library.

[0098] The client knows the function declaration or required parameters (and their types) of the library function, and generates the corresponding data fields based on the parameters required to call the library function (see also...). Figure 5B The data field (620) generates a data field for each parameter, which describes the parameter's type and value. Optionally, the data field may also include a target field to indicate the library function or group of library functions corresponding to the parameter it represents.

[0099] The client packages one or more generated data fields into a network packet and sends it as a request to call a library function to the runtime environment (630). In response to receiving the request, the runtime environment parses the parameters required to call the library function from the network packet and passes them to the dynamic library's dynamic library interface. The runtime environment also packages the result of the library function call from the dynamic library into a network packet and returns it to the client.

[0100] The client receives network data packets (640) provided by the runtime environment and extracts the execution results (650) of the library functions from them.

[0101] The operating environment / client provided in the embodiments of this application includes, for example, a computer, server, or other information processing device. These devices include, for example, memory, one or more processors, one or more presentation components, I / O components, and power supplies that are directly or indirectly coupled to a bus. The bus may represent one or more types of buses (e.g., an address bus, a data bus, or a combination thereof).

[0102] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application. Clearly, those skilled in the art can make various alterations and variations to this application without departing from its spirit and scope. Thus, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An automated integration method for heterogeneous library functions in a heterogeneous library function automated integration system, wherein the heterogeneous library function automated integration system includes a client, a runtime environment, and a function library; the method includes: Obtain the source code of the library functions; Dynamic library interface adapter code is generated based on the source code of the library function. The dynamic library interface adapter code includes the dynamic library interface, library function interface conversion code, and code that calls the library function. The library function interface conversion code is used to convert the dynamic library parameters passed by the dynamic library interface into the library function parameters required to call the library function; Compile and build the source code and the dynamic library interface adapter code to generate a dynamic library that encapsulates the library functions; Load the dynamic library and respond to calls to the library functions using the library functions: In response to receiving a call request for the library function from the client, the system calls the dynamic library interface corresponding to the library function to be called using all parameters in the call request; in response to the dynamic library interface being called, the system converts the parameters at specified positions and a specified number in the dynamic library interface into the data types required to call the library function; and the system calls the library function and passes the converted data type parameters to the library function. The runtime environment contains multiple dynamic libraries, each with a unified interface but encapsulated library functions. For different call requests from clients to different library functions, regardless of whether the number of parameters required to call the library function extracted from different call requests is the same or whether the types of the parameters extracted from different call requests correspond to the same, the generated parameters passed to different dynamic libraries have the same form. The call request includes multiple data fields, and a target field is added to the data fields. The value of the target field represents the library function or group of library functions corresponding to the parameters carried by the data fields, so as to pass the parameters required by multiple library functions to the runtime environment in a single call request. Based on their storage level, dynamic libraries are categorized into file system dynamic libraries, memory dynamic libraries, and current dynamic libraries. When a usable dynamic library needs to be added to the runtime environment, the generated dynamic library is added to a specified location in the file system, becoming a file system dynamic library, which can be loaded and used. One or more file system dynamic libraries are loaded into memory to become memory dynamic libraries. One of the memory dynamic libraries is selected as the current dynamic library to respond to calls to the library functions. The number of memory dynamic libraries is limited. When the capacity of the memory dynamic libraries reaches the upper limit that the runtime environment can accommodate, a least recently used strategy is used to select dynamic libraries to be removed from the memory dynamic libraries.

2. The method according to claim 1, further comprising: In response to receiving a call request for the library function from the client, multiple data fields are extracted from the call request. Each data field corresponds to one of the parameters required to call the library function, and each data field records the type and value of its corresponding parameter. The parameters extracted from the multiple data fields are passed to the dynamic library so that the library function encapsulated by the dynamic library can be called through the dynamic library.

3. The method according to claim 2, wherein For each parameter extracted from the multiple data domains, the extracted parameter type is erased, the multiple parameters with erased types are combined into a variable-length parameter, and the variable-length parameter is passed to the dynamic library.

4. The method according to claim 3, wherein The generated parameters passed to the same or different dynamic libraries are variable-length parameters, and the types of each element carried by the variable-length parameter are erased, or each element has the same specified type.

5. The method according to claim 4, wherein The library function interface conversion code is used to extract the parameters passed to the dynamic library as dynamic library parameters, obtain the types of each parameter required to call the library function according to the function signature of the library function, perform type conversion on the dynamic library parameters, and convert each dynamic library parameter to the parameter type obtained from the function signature of the library function in sequence, wherein the type conversion result of each dynamic library parameter corresponds one-to-one with the type of each parameter required to call the library function in sequence; The code that calls the library function is used to provide the converted dynamic library parameters to the library function.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method according to any one of claims 1-5.

Images