Multithreaded management methods, devices, storage media, and computing equipment
By breaking down multithreaded tasks into business logic sub-logics and executing them concurrently using a JS engine, the thread safety problem is solved, and efficient and stable multithreaded management is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HANGZHOU NETEASE CLOUD MUSIC TECH CO LTD
- Filing Date
- 2024-12-27
- Publication Date
- 2026-06-30
AI Technical Summary
In multithreaded programming, thread safety issues are difficult to resolve effectively through manual coordination, making it difficult to guarantee the correctness and stability of the program.
The business logic of multi-threaded tasks is broken down into different business sub-logics, and different JS engines are used to execute each business code concurrently. Thread safety is ensured through the isolation mechanism of the JS engine.
It eliminates the need to concern oneself with underlying thread safety issues, thus achieving efficient concurrent execution and stability of multi-threaded tasks.
Smart Images
Figure CN122309042A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this disclosure relate to the field of computer technology, and more specifically, the embodiments of this disclosure relate to a multi-threaded management method, apparatus, storage medium, and computing device. Background Technology
[0002] This section is intended to provide background or context for embodiments of this disclosure. The description herein is not intended to imply that it is prior art simply because it is included in this section.
[0003] Multithreading refers to the operation of multiple threads within a single program. A thread is the smallest unit of program execution. A process can contain multiple threads, which can concurrently execute different tasks, thereby improving the program's concurrency and efficiency.
[0004] Modern operating systems typically expose the functionality for creating and scheduling thread tasks to programs through APIs (Application Programming Interfaces). When writing programs, users can use low-level APIs or high-level language interfaces, libraries, or frameworks encapsulated in client-side programming languages to implement multithreaded task development.
[0005] When performing multithreaded programming in a client environment, special attention must be paid to thread safety issues (such as race conditions and deadlocks). Only by ensuring effective synchronization and coordination between the threads in a multithreaded environment can the correctness and stability of the program be guaranteed.
[0006] However, thread safety issues generally require developers to manually coordinate different threads when programming in a multithreaded environment. Limited by personal experience and human error, it is difficult to effectively ensure thread safety in a multithreaded environment. Summary of the Invention
[0007] In a first aspect of this disclosure, a multi-threaded management method is provided. Applied to a client, the method includes:
[0008] Receive a call request for a multi-threaded task sent through a preset call interface; wherein the preset call function uniformly defines the parameter format related to the execution of the multi-threaded task;
[0009] In response to the call request, the parameter information carried in the call request is parsed according to the parameter format, and at least two business codes indicated in the parameter information are obtained; wherein, the at least two business codes include code obtained by encoding the business logic of the multi-threaded task into at least two business sub-logics;
[0010] The business logic of at least two of the components is executed concurrently using different JavaScript engines to complete the multi-threaded task invocation.
[0011] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, including: the interface name of the service interface that encapsulates the business code;
[0012] The business codes for obtaining at least two of the parameters indicated in the parameter information include:
[0013] Obtain at least two interface names from the parameter information, and obtain at least two service interfaces corresponding to the at least two interface names;
[0014] The concurrent execution of the business code of at least two different JS engines includes:
[0015] Use different JS engines to call the service interfaces of the at least two services and execute the business code encapsulated in the at least two service interfaces concurrently.
[0016] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, and also includes: an engine identifier of the JS engine that carries the service interface;
[0017] After parsing the parameter information carried in the call request according to the parameter format, the method further includes:
[0018] Obtain at least two engine identifiers from the parameter information;
[0019] Obtaining the at least two service interfaces corresponding to the at least two interface names includes:
[0020] The at least two interface names are passed to at least two JS engines corresponding to the at least two engine identifiers to determine whether the service interface hosted in each engine matches one of the at least two interface names.
[0021] The use of different JS engines to call the service interfaces of at least two of them includes:
[0022] If both of the at least two JS engines return a hit message, the at least two JS engines are used to call their respective service interfaces to concurrently execute the business code encapsulated in the at least two service interfaces.
[0023] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, including: execution parameters for executing multi-threaded tasks;
[0024] After parsing the parameter information carried in the call request according to the parameter format, the method further includes:
[0025] Obtain the execution parameters from the parameter information;
[0026] When the business code of at least two different JS engines is executed concurrently, the parameter values of the execution parameters are obtained from the native code of the multi-threaded task through the JSI mechanism.
[0027] Optionally, the native code is encoded in C++, and the business code is encoded in JS.
[0028] Optionally, the method further includes:
[0029] Receive an event subscription request for a multi-threaded task; wherein the event subscription request carries subscription parameters, the subscription parameters including the event name to be listened to;
[0030] The subscription parameters are passed to the JS engine so that the JS engine can perform a callback notification based on the subscription parameters when it listens for the target event corresponding to the event name.
[0031] Optionally, the callback notification based on the subscription parameters includes:
[0032] By invoking a preset call function on the client through the JSI mechanism, the scheduler of the multi-threaded task stored in the preset call function is obtained, and then event information related to the monitored target event is notified to the caller via callback.
[0033] Optionally, the client is configured with a shared data space accessible to different JS engines; the JS engine accesses the shared data space through the JSI mechanism, writes shared data into the shared data space for other JS engines to read, or reads shared data written by other JS engines.
[0034] Optionally, after the multi-threaded task is invoked, the following steps are also included:
[0035] The result generated after the call is completed is sent to the caller of the call request in a synchronous or asynchronous callback manner.
[0036] Optionally, before receiving the invocation request for a multi-threaded task sent through a preset invocation interface, the method further includes:
[0037] The business logic of a multi-threaded task is split into at least two business sub-logics, and the at least two business sub-logics are encoded into at least two business codes, and the at least two business codes are encapsulated into at least two service interfaces;
[0038] Create at least two JS engines in the JS engine pool that correspond to the at least two service interfaces, and use the at least two JS engines to host the at least two service interfaces respectively.
[0039] In a second aspect of this disclosure, a multi-threaded management device is provided, applied to a client, the device comprising:
[0040] The receiving unit receives a call request for a multi-threaded task sent through a preset call interface; wherein the preset call function uniformly defines the parameter format related to the execution of the multi-threaded task;
[0041] The parsing unit, in response to the call request, parses the parameter information carried in the call request according to the parameter format, and obtains at least two business codes indicated in the parameter information; wherein, the at least two business codes include code obtained by encoding the business logic of the multi-threaded task into at least two business sub-logics;
[0042] The calling unit uses different JS engines to concurrently execute the business code of at least two of them to complete the invocation of the multi-threaded task.
[0043] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, including: the interface name of the service interface that encapsulates the business code;
[0044] When the parsing unit obtains at least two business codes indicated in the parameter information, it further includes obtaining at least two interface names in the parameter information, and obtaining at least two service interfaces corresponding to the at least two interface names.
[0045] When the calling unit concurrently executes the business code of the at least two using different JS engines, it further includes calling the service interfaces of the at least two using different JS engines and concurrently executing the business code encapsulated in the service interfaces of the at least two.
[0046] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, and also includes: an engine identifier of the JS engine that carries the service interface;
[0047] The parsing unit is also used to obtain at least two engine identifiers from the parameter information;
[0048] When the parsing unit obtains at least two service interfaces corresponding to the at least two interface names, it further includes passing the at least two interface names to at least two JS engines corresponding to the at least two engine identifiers, in order to determine whether the service interface on each engine matches one of the at least two interface names.
[0049] When the calling unit calls the at least two service interfaces using different JS engines, it further includes calling the service interfaces carried by the at least two JS engines when both of the at least two JS engines return a hit message, so as to concurrently execute the business code encapsulated in the at least two service interfaces.
[0050] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, including: execution parameters for executing multi-threaded tasks;
[0051] The parsing unit is also used to obtain the execution parameters in the parameter information;
[0052] When the calling unit executes the business code of the at least two concurrently using different JS engines, it is also used to obtain the parameter values of the execution parameters from the native code of the multi-threaded task through the JSI mechanism.
[0053] Optionally, the native code is encoded in C++, and the business code is encoded in JS.
[0054] Optionally, the device further includes:
[0055] The subscription unit receives event subscription requests for multi-threaded tasks; wherein the event subscription request carries subscription parameters, the subscription parameters including the event name of the event to be listened to;
[0056] The callback unit passes the subscription parameters to the JS engine so that the JS engine can perform a callback notification based on the subscription parameters when it listens for the target event corresponding to the event name.
[0057] Optionally, when the callback unit performs a callback notification based on the subscription parameters, it further includes calling a preset calling function of the client through the JSI mechanism, obtaining the scheduler of the multi-threaded task stored in the preset calling function, and then notifying the caller of event information related to the monitored target event.
[0058] Optionally, the client is configured with a shared data space accessible to different JS engines; the JS engine accesses the shared data space through the JSI mechanism, writes shared data into the shared data space for other JS engines to read, or reads shared data written by other JS engines.
[0059] Optionally, following the calling unit, the following may also be included:
[0060] The return unit sends the call result generated after the call is completed to the caller of the call request in a synchronous or asynchronous callback manner.
[0061] Optionally, prior to the receiving unit, the device further includes:
[0062] The preprocessing unit splits the business logic of the multi-threaded task into at least two business sub-logics, encodes the at least two business sub-logics into at least two business codes, and encapsulates the at least two business codes into at least two service interfaces; it creates at least two JS engines corresponding to the at least two service interfaces in the JS engine pool, and uses the at least two JS engines to carry the at least two service interfaces respectively.
[0063] In a third aspect of this disclosure, a computer-readable storage medium is provided, comprising:
[0064] When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the multi-threaded management method as described in any of the preceding claims.
[0065] In a fourth aspect of this disclosure, a computing device is provided, comprising:
[0066] processor;
[0067] Memory used to store the processor's executable instructions;
[0068] The processor is configured to execute the executable instructions to implement the multithreaded management method as described in the preceding item.
[0069] According to the multi-threaded management scheme provided in this disclosure, by splitting the business logic requiring multi-threaded tasks into different business sub-logics and writing the business code for each business sub-logic using JS, the business code can be executed concurrently by different JS engines when executing multi-threaded tasks to complete the multi-threaded task invocation. Since each JS engine has its own thread, and the threads do not interfere with each other, there is no need to worry about lower-level thread safety issues when using different JS engines to execute multi-threaded tasks concurrently. Attached Figure Description
[0070] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:
[0071] Figure 1 A schematic diagram of the multi-threaded management system provided in this disclosure is shown.
[0072] Figure 2 A schematic diagram illustrating the multi-threaded management method provided in this disclosure is shown.
[0073] Figure 3 A schematic diagram of the medium provided in this disclosure is shown.
[0074] Figure 4 A schematic diagram of the multi-threaded management device provided in this disclosure is shown.
[0075] Figure 5 A schematic diagram of the computing device provided in this disclosure is shown.
[0076] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation
[0077] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.
[0078] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.
[0079] According to embodiments of this disclosure, a multithreaded management method, a computer-readable storage medium, an apparatus, and a computing device are proposed.
[0080] It is important to understand in this article that any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and that any naming is for distinction only and has no limiting meaning.
[0081] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments.
[0082] The data disclosed herein may be data authorized by the user or fully authorized by all parties. The collection, dissemination, and use of the data shall comply with the requirements of relevant national laws and regulations. The implementation methods / executives of this disclosure may be combined with each other. Invention Overview
[0084] This disclosure aims to provide a multi-threaded management scheme. By breaking down the business logic of multi-threaded tasks into different sub-logic, and writing the business code for each sub-logic in JavaScript, different JavaScript engines can be used to execute the various business codes concurrently during the execution of multi-threaded tasks. Since each JavaScript engine has its own thread, and the threads do not interfere with each other, there is no need to worry about lower-level thread safety issues when using different JavaScript engines to execute multi-threaded tasks concurrently.
[0085] After introducing the basic principles of this disclosure, various non-limiting embodiments of this disclosure will be described in detail below.
[0086] Application Scenarios Overview
[0087] First refer to Figure 1 The diagram illustrates a multi-threaded management system. This management system can reside on the client side and is used to manage the multi-threaded tasks that need to be executed on the client.
[0088] The term "client" refers to a program that provides local services to a user, relative to a server. Since the development of the internet, common clients include, but are not limited to, web browsers, email, and instant messaging programs. These programs typically require a remote server or service program to provide services such as HTTP, database, and email.
[0089] like Figure 1 As shown, depending on the functionality, the client may include native code, a JS engine pool, and shared storage.
[0090] Native code can refer to the program code in the client that calls multi-threaded tasks.
[0091] A JavaScript engine pool is used to manage (e.g., create, schedule, distribute, and shut down) various JavaScript engines. A JavaScript engine can refer to a virtual machine that processes JavaScript code; it is responsible for parsing, compiling, and executing JavaScript code. Common JavaScript engines include, but are not limited to, Hermes, JavaScriptCore, QuickJS, and V8.
[0092] Shared storage can refer to a shared data space on the client side that provides shared data storage for JS engines or native code executing multi-threaded tasks. For example... Figure 1 As shown, shared data in shared storage can be stored in the form of key-value pairs.
[0093] This specification provides a solution that eliminates the need for developers to manually ensure thread safety between different threads in a multithreaded environment. This solution involves pre-dividing the business logic of a multithreaded task into different sub-logic, and then writing the business code for each sub-logic using JavaScript. For example... Figure 1 As shown, these business codes can also be encapsulated as service code (API, Application Programming Interface), making it easy to directly call and execute the encapsulated business code through the service interface.
[0094] For the client, to identify which calls are being handled using the multi-threaded approach provided in this manual and which are being handled using the traditional approach, a pre-defined interface with parameters related to multi-threaded task execution can be provided. This interface calls the corresponding business logic or service interfaces that encapsulate this business logic for the multi-threaded task, thereby executing potentially time-consuming sub-logic. Furthermore, the client is automatically notified upon completion or failure of the multi-threaded task call, completing a full asynchronous call process: call - asynchronous thread execution - asynchronous callback.
[0095] Exemplary methods
[0096] The following is combined Figure 1 The application scenarios shown are for reference. Figure 2 This document describes a method for managing multithreading according to exemplary embodiments of the present disclosure. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of the present disclosure, and the embodiments of the present disclosure are not limited in any way. Rather, the embodiments of the present disclosure can be applied to any applicable scenario.
[0097] like Figure 2 As shown, the multi-threaded management method can be applied to the aforementioned client and may include the following steps:
[0098] Step 210: Receive a call request for a multi-threaded task sent through a preset call interface; wherein the preset call function uniformly defines parameter formats related to the execution of multi-threaded tasks.
[0099] Step 220: In response to the call request, parse the parameter information carried in the call request according to the parameter format, and obtain at least two business codes indicated in the parameter information; wherein, the at least two business codes include code obtained by encoding the business logic of the multi-threaded task into at least two business sub-logics.
[0100] Step 230: Execute the business code of at least two different JS engines concurrently to complete the multi-threaded task invocation.
[0101] In this embodiment, in order to identify which call requests are multi-threaded calls and management according to the scheme provided in this specification, and which call requests are multi-threaded calls and management according to the traditional scheme, a preset call interface with a unified definition of the parameter format related to the execution of multi-threaded tasks can be provided to call the various business codes corresponding to the multi-threaded tasks to be executed.
[0102] In an exemplary embodiment, prior to step 210, the method further includes:
[0103] The business logic of a multi-threaded task is split into at least two business sub-logics, and the at least two business sub-logics are encoded into at least two business codes, and the at least two business codes are encapsulated into at least two service interfaces;
[0104] Create at least two JS engines in the JS engine pool that correspond to the at least two service interfaces, and use the at least two JS engines to host the at least two service interfaces respectively.
[0105] In this embodiment, the business logic of the multi-threaded task is split into at least two business sub-logics. The business logic can be split according to the function or module of the multi-threaded task, and it is necessary to ensure that the logic of the split business sub-logics is complete and can be executed independently by the subsequent JS engine.
[0106] like Figure 1 As shown, for multi-threaded tasks, the business logic of the multi-threaded task can be pre-divided into different business sub-logics, and the business code of each business sub-logic can be written using the JS language. Furthermore, these business codes can be encapsulated into corresponding service codes, so that the native client code of other programs in the client can directly call and execute the encapsulated business code through the service interface.
[0107] Based on this, in an exemplary embodiment, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, which may include: the interface name of the service interface that encapsulates the business code;
[0108] Accordingly, step 220, when obtaining the business codes of at least two indicated in the parameter information, may further include:
[0109] Obtain at least two interface names from the parameter information, and obtain at least two service interfaces corresponding to the at least two interface names.
[0110] Additionally, step 230, when concurrently executing the business code of the at least two using different JS engines, may further include:
[0111] Use different JS engines to call the service interfaces of the at least two services and execute the business code encapsulated in the at least two service interfaces concurrently.
[0112] This embodiment encapsulates the business code of the business sub-logic split from the multi-threaded task into a service interface, and defines interface parameters in the preset call interface to indicate the service interface to be called; in this way, when the caller calls the preset call interface to request the execution of the multi-threaded task, the interface name of each service interface corresponding to the multi-threaded task is automatically written into the preset call interface as a parameter value, thereby passing the interface name of each service interface to be called.
[0113] It should be noted that the parameter format of the preset call interface, in addition to the interface name mentioned above, may also include the engine identifier of the JS engine, execution parameters required for multi-threaded task execution, etc. The following are exemplary examples of each parameter in the parameter format, and their definitions:
[0114] 1) `module`: This parameter refers to the target module name invoked by the caller (the party initiating the call). Here, the module name can refer to the module used to split the business logic of a multi-threaded task into at least two sub-logic logics, as mentioned earlier. In this case, the service code encoding the sub-logic logic and the service interface encapsulating the service code will have this `module name` parameter. A module can contain one or more service interfaces.
[0115] 2) method: This parameter refers to the interface name of the target service interface called by the caller.
[0116] 3) args: This parameter refers to the execution parameters required for multi-threaded execution. This parameter needs to be passed to the target service interface so that the target service interface can execute the encapsulated business code based on the execution parameters.
[0117] 4) source: This parameter refers to the engine identifier of the JS engine of the caller (a fixed value for the client).
[0118] 5) target: This parameter refers to the engine identifier of the target JS engine where the target service interface is located.
[0119] Upon receiving a call request sent through such a preset call interface, the system parses the various parameter information carried in the call request according to the defined parameter format.
[0120] For example, the corresponding service interface can be found and called through method and args; the target JS engine for executing the service interface can be found through target; and the execution parameters required for the execution of the service code encapsulated by the service interface can be obtained through args, etc.
[0121] The following section provides further explanation of some parameters defined in the preset calling function, along with relevant examples.
[0122] [target: Engine identifier]
[0123] In one exemplary embodiment, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, and may also include: an engine identifier of the JS engine carrying the service interface;
[0124] Accordingly, after parsing the parameter information carried in the call request according to the parameter format, step 220 may further include:
[0125] Obtain at least two engine identifiers from the parameter information;
[0126] Accordingly, the aforementioned acquisition of at least two service interfaces corresponding to the at least two interface names may further include:
[0127] The at least two interface names are passed to at least two JS engines corresponding to the at least two engine identifiers to determine whether the service interface hosted in each engine matches one of the at least two interface names.
[0128] In addition, the aforementioned use of different JS engines to call the service interfaces of the at least two can further include:
[0129] If both of the at least two JS engines return a hit message, the at least two JS engines are used to call their respective service interfaces to concurrently execute the business code encapsulated in the at least two service interfaces.
[0130] In this embodiment, the engine identifier can be maintained using the engine ID. The engine identifier is automatically assigned when the JS engine is created, and it is necessary to record and maintain the correspondence between each engine identifier and the corresponding JS engine, and automatically find the target JS engine based on the engine identifier when parsing the call request.
[0131] Generally, when a client process starts, it will create at least one JS engine to execute task code. Depending on the task load, such as when the current JS engine is executing a time-consuming task, a new JS engine will be created as needed.
[0132] like Figure 1As shown, these created JS engines can be managed within a JS engine pool. Furthermore, to ensure system performance, idle JS engines can be periodically recycled to release system resources occupied by them.
[0133] In addition, to improve execution efficiency, after encapsulating the business code of each business sub-logic into service interfaces, a JS engine can be assigned to each service interface to host it, thereby binding the service interface to the JS engine. For example... Figure 1 As shown, different JS engine instances host different service interfaces.
[0134] The JS engine can determine whether it needs to call the service interface it hosts based on the passed method parameter. If the interface name indicated by the method parameter is consistent with the service interface it hosts, it returns a hit message, indicating that the service interface it hosts is the service interface corresponding to the multi-threaded task to be executed.
[0135] [args: Execution parameters]
[0136] In one exemplary embodiment, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, which may include: execution parameters for executing multi-threaded tasks;
[0137] Accordingly, after parsing the parameter information carried in the call request according to the parameter format, step 220 may further include:
[0138] Obtain the execution parameters from the parameter information;
[0139] Accordingly, when the aforementioned business code of at least two tasks is executed concurrently using different JS engines, the parameter values of the execution parameters can be obtained from the native code of the multi-threaded task through the JSI mechanism.
[0140] In this embodiment, although the execution parameters required for the execution of the multi-threaded task can be passed to the JS engine through args, the specific parameter values still need to be obtained by the JS engine from the native code of the multi-threaded task.
[0141] For example, when the native code of a multithreaded task is coded in C++, while the business logic code carried by the JS engine is coded in JS, the JS engine can obtain the parameter values of the execution parameters by means of the JSI mechanism.
[0142] JSI (JavaScript Interface) refers to the interface between JavaScript and C++, used to enable communication and interaction between the two. When the JS engine executes business code, the parameter values of each execution parameter can be passed from the C++ code of the multi-threaded task on the client side to the JS engine through the JSI mechanism, so that the JS engine can execute its respective business code based on the parameter values.
[0143] In practical applications, since each business code is derived from the business logic of the same multi-threaded task, different JS engines may need to obtain data generated during the execution of other JS engines when executing their respective business code. This type of data can be called shared data.
[0144] However, data between different JS engines is isolated by default. This leads to the problem that JS engines that need to obtain data generated during the execution of other JS engines in order to execute business code cannot execute normally.
[0145] Therefore, as before Figure 1 As shown in the diagram, this specification also includes a shared data space at the client-side level, providing shared data storage for JS engines executing multi-threaded tasks. Different JS engines can access this shared data space to write to or read shared data.
[0146] For example, this process can be implemented using the JSI mechanism, that is, the JS engine can access the shared data space through the JSI mechanism, write shared data into the shared data space for other JS engines to read, or read shared data written by other JS engines.
[0147] This embodiment can address the problem of JS engines being unable to execute properly due to data isolation between different JS engines, which requires data generated during the execution of other JS engines in order to execute business code.
[0148] Furthermore, after completing the multi-threaded task call by concurrently executing at least two business codes using different JS engines through step 230, the call result generated after the call can be sent to the caller of the call request in a synchronous or asynchronous callback manner.
[0149] As before Figure 1 As shown, in addition to providing the ability to execute at least two business codes concurrently using different JS engines to complete the multi-threaded task invocation, the client also provides an event subscription mechanism.
[0150] In one exemplary embodiment, in the foregoing Figure 2 Based on the illustrated embodiments, it may also include:
[0151] Receive an event subscription request for a multi-threaded task; wherein the event subscription request carries subscription parameters, the subscription parameters including the event name to be listened to;
[0152] The subscription parameters are passed to the JS engine so that the JS engine can perform a callback notification based on the subscription parameters when it listens for the target event corresponding to the event name.
[0153] Regarding the callback notification, in an exemplary embodiment, a preset calling function of the client can be invoked through the JSI mechanism to obtain the scheduler of the multi-threaded task stored in the preset calling function, and then the event information related to the monitored target event can be callbackly notified to the caller.
[0154] In this embodiment, the event name of the target event to be listened to can be passed to the JS engine based on the event subscription mechanism. For example, the module name, event name, and a generated unique ID can be passed to the JS engine as subscription parameters.
[0155] The JavaScript engine can further associate this information with the callers that invoked or called multithreaded tasks (the same association can also be stored in the client), so that when a target event is detected, callback notifications can be completed based on the associations. When the JavaScript engine needs to notify the callers, it can look up the associations to obtain all the callers, and sequentially call the client's preset calling functions through the JSI mechanism to pass the event information related to the detected target event to the client. Then, the client, based on the stored list of all callers that invoked or called multithreaded tasks, sequentially sends callback notifications containing the event information related to the detected target event to these callers.
[0156] The above embodiments enable event subscription for multi-threaded tasks under the JS engine, thereby satisfying the caller's need to listen to target events in multi-threaded tasks.
[0157] In summary, the multithreading management method provided in this specification breaks down the business logic of multithreaded tasks into different sub-logic and writes the business code for each sub-logic in JavaScript. This allows different JavaScript engines to execute these sub-logic concurrently during multithreaded task execution, thus completing the multithreaded task invocation. Since each JavaScript engine has its own thread, and these threads do not interfere with each other, there is no need to worry about lower-level thread safety issues when using different JavaScript engines to execute multithreaded tasks concurrently.
[0158] Exemplary media
[0159] After introducing the methods of exemplary embodiments of this disclosure, the following references are made. Figure 3 The medium for exemplary embodiments of this disclosure will be described.
[0160] In this exemplary embodiment, the above method can be implemented by a program product, such as a portable compact disc read-only memory (CD-ROM) containing program code, which can run on a device, such as a personal computer. However, the program product disclosed herein is not limited thereto. In this document, a readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0161] The program product may employ any combination of one or more readable media. A readable media may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0162] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.
[0163] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RE, etc., or any suitable combination thereof.
[0164] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).
[0165] In summary, this disclosure provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by the processor of an electronic device, enables the electronic device to perform the aforementioned multi-threaded management method embodiments.
[0166] Exemplary device
[0167] Having introduced the medium of exemplary embodiments of this disclosure, the following references are made to... Figure 4 An apparatus according to an exemplary embodiment of the present disclosure will be described.
[0168] Figure 4 A block diagram schematically illustrates a multi-threaded management device according to an embodiment of the present disclosure, corresponding to the foregoing Figure 2 The method embodiment shown is applied to a client; the multi-threaded management device may include:
[0169] The receiving unit 410 receives a call request for a multi-threaded task sent through a preset call interface; wherein the preset call function uniformly defines a parameter format related to the execution of the multi-threaded task.
[0170] The parsing unit 420, in response to the call request, parses the parameter information carried in the call request according to the parameter format, and obtains at least two business codes indicated in the parameter information; wherein, the at least two business codes include code obtained by encoding the business logic of the multi-threaded task into at least two business sub-logics;
[0171] Calling unit 430 uses different JS engines to concurrently execute the business code of at least two of them to complete the invocation of the multi-threaded task.
[0172] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, including: the interface name of the service interface that encapsulates the business code;
[0173] When the parsing unit 420 obtains at least two business codes indicated in the parameter information, it further includes obtaining at least two interface names in the parameter information and obtaining at least two service interfaces corresponding to the at least two interface names.
[0174] When the calling unit 430 concurrently executes the business code of the at least two using different JS engines, it further includes calling the service interfaces of the at least two using different JS engines and concurrently executing the business code encapsulated in the service interfaces of the at least two.
[0175] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, and also includes: an engine identifier of the JS engine that carries the service interface;
[0176] The parsing unit 420 is also used to obtain at least two engine identifiers from the parameter information;
[0177] When the parsing unit 420 obtains at least two service interfaces corresponding to the at least two interface names, it further includes passing the at least two interface names to at least two JS engines corresponding to the at least two engine identifiers to determine whether the service interface on each engine matches one of the at least two interface names.
[0178] When the calling unit 430 calls the at least two service interfaces using different JS engines, it further includes calling the service interfaces carried by the at least two JS engines using the at least two JS engines when both of the at least two JS engines return a hit message, so as to concurrently execute the business code encapsulated in the at least two service interfaces.
[0179] Optionally, the preset calling function uniformly defines a parameter format related to the execution of multi-threaded tasks, including: execution parameters for executing multi-threaded tasks;
[0180] The parsing unit 420 is also used to obtain the execution parameters in the parameter information;
[0181] When the calling unit 430 executes the business code of the at least two concurrently using different JS engines, it is also used to obtain the parameter value of the execution parameter from the native code of the multi-threaded task through the JSI mechanism.
[0182] Optionally, the native code is encoded in C++, and the business code is encoded in JS.
[0183] Optionally, the device further includes:
[0184] Subscription unit 440 receives event subscription requests for multi-threaded tasks; wherein, the event subscription request carries subscription parameters, the subscription parameters including the event name of the event to be listened to;
[0185] Callback unit 450 passes the subscription parameters to the JS engine so that the JS engine can perform a callback notification based on the subscription parameters when it listens for the target event corresponding to the event name.
[0186] Optionally, when the callback unit 450 performs callback notification based on the subscription parameters, it further includes calling a preset calling function of the client through the JSI mechanism, obtaining the scheduler of the multi-threaded task stored in the preset calling function, and then notifying the caller of event information related to the monitored target event.
[0187] Optionally, the client is configured with a shared data space accessible to different JS engines; the JS engine accesses the shared data space through the JSI mechanism, writes shared data into the shared data space for other JS engines to read, or reads shared data written by other JS engines.
[0188] Optionally, after the calling unit 430, the following may also be included:
[0189] Return unit 432 sends the call result generated after the call is completed to the caller of the call request in a synchronous or asynchronous callback manner.
[0190] Optionally, prior to the receiving unit 410, the device further includes:
[0191] The preprocessing unit 402 splits the business logic of the multi-threaded task into at least two business sub-logics, encodes the at least two business sub-logics into at least two business codes, and encapsulates the at least two business codes into at least two service interfaces; it creates at least two JS engines in the JS engine pool corresponding to the at least two service interfaces, and uses the at least two JS engines to carry the at least two service interfaces respectively.
[0192] Exemplary computing device
[0193] Having described the methods, media, and apparatus of exemplary embodiments of this disclosure, the following references... Figure 5 A computing device according to an exemplary embodiment of the present disclosure will be described.
[0194] Figure 5 The computing device 1500 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0195] like Figure 5As shown, the computing device 1500 is presented in the form of a general-purpose computing device. The components of the computing device 1500 may include, but are not limited to: at least one processing unit 1501, at least one storage unit 1502, and a bus 1503 connecting different system components (including the processing unit 1501 and the storage unit 1502).
[0196] Bus 1503 includes a data bus, a control bus, and an address bus.
[0197] Storage unit 1502 may include readable media in the form of volatile memory, such as random access memory (RAM) 15021 and / or cache memory 15022, and may further include readable media in the form of non-volatile memory, such as read-only memory (ROM) 15023.
[0198] Storage unit 1502 may also include a program / utility 15025 having a set (at least one) of program modules 15024, such program modules 15024 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.
[0199] The computing device 1500 can also communicate with one or more external devices 1504 (such as a keyboard, pointing device, etc.).
[0200] This communication can be performed via input / output (I / O) interface 1505. Furthermore, the computing device 1500 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapter 1506. Figure 5 As shown, network adapter 1506 communicates with other modules of computing device 1500 via bus 1503. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with computing device 1500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0201] Through such Figure 5 The computing device 1500 shown can implement the aforementioned multi-threaded management method. More specifically, the storage unit 1502 stores the instructions executable by the processing unit 1501, and the processing unit 1501 implements the aforementioned multi-threaded management method when executing the instructions.
[0202] It should be noted that although several units / modules or sub-units / modules of the multi-threaded management device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.
[0203] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.
[0204] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
Claims
1. A multi-threaded management method, applied to a client, the method comprising: Receive a call request for a multi-threaded task sent through a preset call interface; wherein the preset call function uniformly defines the parameter format related to the execution of the multi-threaded task; In response to the call request, the parameter information carried in the call request is parsed according to the parameter format, and at least two business codes indicated in the parameter information are obtained; wherein, the at least two business codes include code obtained by encoding the business logic of the multi-threaded task into at least two business sub-logics; The business logic of at least two of the components is executed concurrently using different JavaScript engines to complete the multi-threaded task invocation.
2. The method of claim 1, wherein a format of parameters related to execution of the multithreaded task is uniformly defined in the preset calling function, comprising: The interface name of the service interface that encapsulates the business code; The business codes for obtaining at least two of the parameters indicated in the parameter information include: Obtain at least two interface names from the parameter information, and obtain at least two service interfaces corresponding to the at least two interface names; The concurrent execution of the business code of at least two different JS engines includes: Use different JS engines to call the service interfaces of the at least two services and execute the business code encapsulated in the at least two service interfaces concurrently.
3. The method of claim 2, wherein the preset calling function has a parameter format related to execution of the multi-threaded task uniformly defined therein, further comprising: The engine identifier of the JS engine that carries the service interface; After parsing the parameter information carried in the call request according to the parameter format, the method further includes: Obtain at least two engine identifiers from the parameter information; Obtaining the at least two service interfaces corresponding to the at least two interface names includes: The at least two interface names are passed to at least two JS engines corresponding to the at least two engine identifiers to determine whether the service interface hosted in each engine matches one of the at least two interface names. The use of different JS engines to call the service interfaces of at least two of them includes: If both of the at least two JS engines return a hit message, the at least two JS engines are used to call their respective service interfaces to concurrently execute the business code encapsulated in the at least two service interfaces.
4. The method of claim 1, wherein a format of parameters related to execution of the multithreaded task is uniformly defined in the preset calling function, comprising: Execution parameters for multithreaded tasks; After parsing the parameter information carried in the call request according to the parameter format, the method further includes: Obtain the execution parameters from the parameter information; When the business code of at least two different JS engines is executed concurrently, the parameter values of the execution parameters are obtained from the native code of the multi-threaded task through the JSI mechanism.
5. The method according to claim 4, wherein the native code is encoded in C++ and the business code is encoded in JS.
6. The method according to claim 1, further comprising: Receive an event subscription request for a multi-threaded task; wherein the event subscription request carries subscription parameters, the subscription parameters including the event name to be listened to; The subscription parameters are passed to the JS engine so that the JS engine can perform a callback notification based on the subscription parameters when it listens for the target event corresponding to the event name.
7. The method according to claim 6, wherein the callback notification based on the subscription parameters includes: By invoking a preset call function on the client through the JSI mechanism, the scheduler of the multi-threaded task stored in the preset call function is obtained, and then event information related to the monitored target event is notified to the caller via callback.
8. A multi-threaded management device, applied to a client, the device comprising: The receiving unit receives a call request for a multi-threaded task sent through a preset call interface; wherein the preset call function uniformly defines the parameter format related to the execution of the multi-threaded task; The parsing unit, in response to the call request, parses the parameter information carried in the call request according to the parameter format, and obtains at least two business codes indicated in the parameter information; wherein, the at least two business codes include code obtained by encoding the business logic of the multi-threaded task into at least two business sub-logics; The calling unit uses different JS engines to concurrently execute the business code of at least two of them to complete the invocation of the multi-threaded task.
9. A computer-readable storage medium, comprising: When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the multi-threaded management method as described in any one of claims 1-7.
10. A computing device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the executable instructions to implement the multi-threaded management method as described in any one of claims 1-7.