Inter-process communication method, system, device, and medium

Abstract

The application discloses an inter-process communication method, system, device and medium, and belongs to the technical field of inter-process communication. As long as a process completes registration on a message bus and saves a message hub identifier of the process to a message hub list, the process can both listen to messages corresponding to an executor identifier as a receiving end process and implement data receiving, and can also send data as a sending end process by specifying a message hub identifier and an executor identifier and carrying a message parameter. In the application, an inter-process communication scheme based on a multi-path message bus distribution mechanism is provided. The scheme supports message sending of a specified process and supports a process registration mechanism based on a message bus, decouples a sending message process from a receiving message process, and even when only the sending message process is registered, the process will not crash due to the absence of the receiving message process registration.

Description

Technical Field

[0001] This application relates to the field of inter-process communication technology, and in particular to an inter-process communication method, an inter-process communication system, an inter-process communication device, and a computer-readable storage medium. Background Technology

[0002] In the Linux platform, inter-process communication (IPC) is primarily used for process scheduling, resource sharing between processes, and data transfer. Based on these IPC requirements, the Linux platform provides developers with primitive-based solutions. These solutions mainly include: signals, pipes, named pipes, sockets, semaphores, shared memory, and message queues.

[0003] For simple data transfer and event notification between processes, an event callback communication mechanism is generally used. This mechanism is simple and easy to implement. However, when using event callbacks for inter-process communication, an exception can occur where the Callback Object returns a null pointer, causing the calling process to crash and thus affecting its normal functionality. Summary of the Invention

[0004] The main objective of this application is to provide an inter-process communication method, an inter-process communication system, an inter-process communication device, and a computer-readable storage medium, aiming to solve the technical problem in the prior art where a process crashes due to the absence of a process receiving a message.

[0005] To achieve the above objectives, this application provides an inter-process communication method, which is applied to a sending process and includes: Create a message by specifying the message hub identifier of the receiving process through a publicly shared list of message hubs, specifying the executor identifier of the receiving process through a publicly shared list of executors, and specifying the message parameters to be carried, and obtain the target message; The target message is uploaded to the message bus via the message hub, and then forwarded to the receiving process via the message bus.

[0006] In one embodiment, the method further includes: If multiple message hub identifiers are specified in the target message, the target message is forwarded to multiple receiving processes corresponding to the multiple message hub identifiers through the message bus; If the message hub identifier is not specified in the target message, the target message is forwarded to all receiving processes corresponding to the message hub list via the message bus.

[0007] To achieve the above objectives, this application provides an inter-process communication method, which is applied to a message bus and includes: The receiving end process receives the target message uploaded through the message hub and parses the target message to obtain the message hub identifier of the receiving end process. Traverse the publicly shared list of message hubs, determine the target message hub of the receiving process corresponding to the message hub identifier, and send the target message to the target message hub.

[0008] In one embodiment, before the step of receiving the target message uploaded by the sending process through the message hub, the method further includes: Receive the message hub identifier uploaded by each process through the message hub, save the message hub identifier in the message hub list, and publicly share the message hub list.

[0009] In one embodiment, after the step of traversing the publicly shared list of message hubs, the method further includes: If the target message hub corresponding to the message hub identifier is not found in the message hub list, then wait for the target receiving process with the message hub identifier to be created. After receiving the message hub identifier uploaded by the target receiving process and saving it to the message hub list, execute the step of traversing the publicly shared message hub list.

[0010] To achieve the above objectives, this application provides an inter-process communication method, which is applied to a receiving process and includes: The message hub receives the target message sent by the message bus and parses the target message to obtain the actuator identifier and message parameters. The target executor corresponding to the executor identifier is determined by the executor list, and the target executor is invoked to process the message parameters.

[0011] In one embodiment, before the step of receiving the target message sent by the message bus through the message hub, the method further includes: The message hub uploads its message hub identifier to the message bus via the message hub, so that the message bus stores the message hub identifier in the message hub list.

[0012] In one embodiment, before the step of receiving the target message sent by the message bus through the message hub, the method further includes: The executor identifier of the executor is determined based on the message sent by the sending process that the executor is listening to; Save the actuator identifier of the actuator to the actuator list, and publicly share the actuator list.

[0013] This application also provides an inter-process communication system, the system comprising: The sending process implements the inter-process communication method described above; A message bus that implements the inter-process communication method described above; Implement the receiving process of the inter-process communication method described above.

[0014] This application also provides an inter-process communication device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the inter-process communication method as described above.

[0015] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described inter-process communication method.

[0016] This application discloses an inter-process communication (IPC) method, IPC system, IPC device, and computer-readable storage medium. In the sending process, a message is created, and the message hub identifier of the receiving process is specified through a publicly shared message hub list. The executor identifier of the receiving process is specified through a publicly shared executor list, and the message parameters are specified to obtain a target message. The target message is then uploaded to a message bus via the message hub, and forwarded to the receiving process via the message bus. On the message bus, the target message uploaded by the sending process via the message hub is received, and the target message is parsed to obtain the message hub identifier of the receiving process. The publicly shared message hub list is traversed to determine the target message hub of the receiving process corresponding to the message hub identifier, and the target message is sent to the target message hub. In the receiving process, the target message sent by the message bus is received via the message hub, and the target message is parsed to obtain the executor identifier and message parameters. The target executor corresponding to the executor identifier is determined through the executor list, and the target executor is invoked to process the message parameters.

[0017] In this application, the sending process obtains the target message by specifying a message hub identifier and an executor identifier, along with message parameters; then, it forwards the target message to the receiving process via the message bus. On the message bus, the target message received from the sending process is parsed to obtain the message hub identifier of the receiving process, the receiving process corresponding to the message hub identifier is determined, and the target message is sent to the target message hub. On the receiving process, the target message sent by the message bus is parsed to obtain the executor identifier and message parameters; then, the target executor corresponding to the executor identifier is determined, and the target executor is invoked to process the message parameters.

[0018] In this application, as long as a process completes registration on the message bus and saves its message hub identifier to the message hub list, it can act as both a receiving process listening to messages corresponding to the executor identifier to receive data, and a sending process sending data by specifying the message hub identifier and executor identifier and carrying message parameters. This application provides an inter-process communication scheme based on a multi-channel message bus distribution mechanism. It supports specifying a process to send messages and also supports a process registration mechanism based on the message bus, decoupling the sending process from the receiving process. Even when only the sending process is registered, the process will not crash due to the absence of a receiving process. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the structure of the operating device of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a schematic diagram of an event callback-based communication mechanism. Figure 3 This is a schematic diagram of a communication model based on a multiplex message bus distribution mechanism, which is an embodiment of the inter-process communication method involved in the present application. Figure 4 This is a schematic diagram of the system architecture of an embodiment of the inter-process communication method involved in the present application. Figure 5 This is a flowchart illustrating an embodiment of the inter-process communication method involved in the present application. Figure 6 This is a flowchart illustrating another embodiment of the inter-process communication method involved in the embodiments of this application; Figure 7 This is a schematic diagram illustrating process decoupling of an embodiment of the inter-process communication method involved in the present application. Figure 8 This is a flowchart illustrating another embodiment of the inter-process communication method involved in the embodiments of this application; Figure 9This is a schematic diagram illustrating the inter-module communication operation of an application example of the inter-process communication method involved in the embodiments of this application.

[0020] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0022] Reference Figure 1 , Figure 1 This is a schematic diagram of the operating device structure of the hardware operating environment involved in the embodiments of this application.

[0023] like Figure 1 As shown, the operating device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0024] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the operating equipment and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0025] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and computer programs.

[0026] exist Figure 1In the illustrated operating device, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and memory 1005 in the operating device of this application can be disposed in the operating device, and the operating device calls the computer program stored in the memory 1005 through the processor 1001 and performs the following operations: Create a message by specifying the message hub identifier of the receiving process through a publicly shared list of message hubs, specifying the executor identifier of the receiving process through a publicly shared list of executors, and specifying the message parameters to be carried, and obtain the target message; The target message is uploaded to the message bus via the message hub, and then forwarded to the receiving process via the message bus.

[0027] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: If multiple message hub identifiers are specified in the target message, the target message is forwarded to multiple receiving processes corresponding to the multiple message hub identifiers through the message bus; If the message hub identifier is not specified in the target message, the target message is forwarded to all receiving processes corresponding to the message hub list via the message bus.

[0028] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: The receiving end process receives the target message uploaded through the message hub and parses the target message to obtain the message hub identifier of the receiving end process. Traverse the publicly shared list of message hubs, determine the target message hub of the receiving process corresponding to the message hub identifier, and send the target message to the target message hub.

[0029] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: Before the step of receiving the target message uploaded by the sending process through the message hub, the method further includes: Receive the message hub identifier uploaded by each process through the message hub, save the message hub identifier in the message hub list, and publicly share the message hub list.

[0030] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: Following the step of traversing the publicly shared list of message hubs, the method further includes: If the target message hub corresponding to the message hub identifier is not found in the message hub list, then wait for the target receiving process with the message hub identifier to be created. After receiving the message hub identifier uploaded by the target receiving process and saving it to the message hub list, execute the step of traversing the publicly shared message hub list.

[0031] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: The message hub receives the target message sent by the message bus and parses the target message to obtain the actuator identifier and message parameters. The target executor corresponding to the executor identifier is determined by the executor list, and the target executor is invoked to process the message parameters.

[0032] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: Before the step of receiving the target message sent from the message bus through the message hub, the method further includes: The message hub uploads its message hub identifier to the message bus via the message hub, so that the message bus stores the message hub identifier in the message hub list.

[0033] In one embodiment, the processor 1001 may invoke a computer program stored in the memory 1005 and further perform the following operations: Before the step of receiving the target message sent from the message bus through the message hub, the method further includes: The executor identifier of the executor is determined based on the message sent by the sending process that the executor is listening to; Save the actuator identifier of the actuator to the actuator list, and publicly share the actuator list.

[0034] Reference Figure 2In the event callback-based communication mechanism, a Callback Object is created in Progress2 and registered with the Factory Object in Progress2. The Callback Object is then added to the Callback Object List in the Factory Object. The Callback Object created in Progress2 inherits from the Callback Parent interface class in Progress1. Therefore, when the Factory Object in Progress2 processes a Function, it sequentially retrieves the Callback Parent instances from the Callback Object List, ultimately calling the CallbackFunction within the Callback Parent instance in Progress1.

[0035] right Figure 2 As shown in the example of the Callback Object in Progress1, the Callback Object registers its own pointer with Progress2, that is, it adds the pointer corresponding to the Callback Object to the Callback Object List in the Factory Object. However, when the Function in the Factory Object retrieves the Callback Object from the Callback Object List to execute the Callback Function, if the Callback Object in Process1 has been destroyed at this time, a NullPointerException will occur when the Function in Progress2 is executed, causing Progress2 to crash and become unusable.

[0036] Reference Figure 3 This application provides an inter-process communication system, the system comprising: Implement the sending process of the inter-process communication method described below; Implement a message bus for the inter-process communication method described below; Implement the receiving process of the inter-process communication method described below.

[0037] This approach essentially treats the MessageBus as a server, with the receiving and sending processes acting as clients. Specifically: 1) The MessageBus itself is a process that needs to be started before any processes that rely on it for communication; 2) Processes A / B / C register with the MessageBus after startup. Each process can act as either a sender (S) or a receiver (R); 3) Process A registers to listen for the message type Message_ID_1, Process B registers to listen for the message type Message_ID_2, and Process C registers to listen for the message type Message_ID_3; 4) Any message of type Message_ID_1 sent by any process in A / B / C will be received by Process A. Similarly, any message of type Message_ID_2 or Message_ID_3 sent by any process will be received by Process B or Process C.

[0038] Reference Figure 4 The Message Bus based on this solution mainly consists of four parts: MessageHubManager, MessageHub, Message, and Message-Param.

[0039] The MessageHubManager is primarily used to register and unregister MessageHubs created by communication processes, and to maintain a MessageHubList (a list of message hubs). Each process that needs to communicate using the MessageBus must create a MessageHub object identified by its ModuleId (message hub identifier) ​​and register it with the MessageBus. The MessageHubList is a publicly accessible shared list between processes and the message bus. Each communicating process has only one Message Hub; sending and receiving messages are all done through this single Message Hub.

[0040] The MessageHub is primarily used for registering and deregistering Handlers (executors). These Handlers handle received Messages with a specific ModuleId and messageId (executor identifier); createMessages with a specific MessageId; and sendMessages to a specific MessageHub object based on the ModuleId. Both sending and receiving data between processes are implemented by the message hub. It also maintains a HandlerList (executor list), which is a publicly accessible and shared list among all processes.

[0041] The Message is mainly used to contain the data that needs to be communicated, namely the Message-Param, and the messageId used to uniquely identify the Message. When other processes receive the Message, they will use the messageId to match the specified handler to process the Message.

[0042] The Message-Param function mainly includes the getParamX function, which retrieves the specific information contained in the Message-Param.

[0043] In this embodiment, as long as a process completes registration on the message bus and saves its message hub identifier to the message hub list, it can act as both a receiving process listening to messages corresponding to the executor identifier to receive data, and a sending process sending data by specifying the message hub identifier and executor identifier and carrying message parameters. This embodiment provides an inter-process communication scheme based on a multi-channel message bus distribution mechanism. It supports specifying a process to send messages and also supports a process registration mechanism based on the message bus, decoupling the sending process from the receiving process. Even when only the sending process is registered, the process will not crash due to the absence of a receiving process.

[0044] This application provides an inter-process communication method, referring to... Figure 5 In one embodiment of the inter-process communication method, the method is applied to the sending process and includes: Step A: Create a message by specifying the message hub identifier of the receiving process through a publicly shared list of message hubs, specifying the executor identifier of the receiving process through a publicly shared list of executors, and specifying the message parameters to be carried, thereby obtaining the target message; In this embodiment, after a message is created, a publicly and transparently shared MessageHubList is established between the process and the message bus. The message hub identifier of the receiving process is specified in the message hub list. This message hub identifier indicates the message hub of the receiving process. Since there is a one-to-one correspondence between message hubs and processes, and between processes and message hubs, it is equivalent to using the message hub identifier to indicate the receiving process. A publicly and transparently shared HandlerList is established between the processes. The executor identifier of the receiving process is specified in the executor list. This executor identifier indicates the executor in the receiving process used to process the target message. After specifying the message hub identifier and the executor identifier, the message parameters to be carried in the message are specified to obtain the target message. This allows it to be determined that the receiving process corresponding to the message hub identifier will receive the target message, and the corresponding executor of the corresponding receiving process will process the message parameters in the target message. The specified receiving ModuleID can be the message hub identifier of the sending process itself, thus achieving a function similar to loopback detection.

[0045] Step B involves uploading the target message to the message bus via the message hub, and then forwarding the target message to the receiving process via the message bus.

[0046] Reference Figure 3 After receiving the target message, the sending process uploads it to the message bus via the message hub. The message bus then forwards the target message to the receiving process, which in turn sends it to the executor identified in the target message to process the message parameters. Thus, the sending process communicates with the receiving process by calling methods within the receiving process.

[0047] For example, the method further includes: If multiple message hub identifiers are specified in the target message, the target message is forwarded to multiple receiving processes corresponding to the multiple message hub identifiers through the message bus; If the message hub identifier is not specified in the target message, the target message is forwarded to all receiving processes corresponding to the message hub list via the message bus.

[0048] If the sending process specifies multiple message hub identifiers when defining the target message, the target message is forwarded to multiple receiving processes corresponding to the multiple message hub identifiers in the message hub list via the message bus. The sending process communicates with multiple receiving processes that have been registered in the message hub list.

[0049] If the sending process does not specify a message hub identifier when defining the target message, the target message is forwarded to all corresponding receiving processes in the message hub list via the message bus, and the sending process communicates with all receiving processes that have been registered in the message hub list.

[0050] In this embodiment, the sending process creates a message, specifies the message hub identifier of the receiving process through a publicly shared message hub list, specifies the executor identifier of the receiving process through a publicly shared executor list, and specifies the message parameters to be carried, thus obtaining the target message. The target message is then uploaded to the message bus via the message hub, and forwarded to the receiving process via the message bus. In the sending process, the target message is obtained by specifying the message hub identifier and executor identifier, and carrying message parameters; the target message is then forwarded to the receiving process via the message bus.

[0051] Therefore, as long as a process completes registration on the message bus and saves its message hub identifier to the message hub list, it can act as both a receiving process listening to messages corresponding to the executor identifier to receive data, and a sending process sending data by specifying the message hub identifier and executor identifier and carrying message parameters. This embodiment provides an inter-process communication scheme based on a multi-channel message bus distribution mechanism, supporting designated processes to send messages and a process registration mechanism based on the message bus, decoupling the sending and receiving processes. Even when only the sending process is registered, the process will not crash due to the absence of a receiving process.

[0052] This application provides an inter-process communication method, referring to... Figure 6 In one embodiment of the inter-process communication method, the method is applied to a message bus and includes: Step M: Receive the target message uploaded by the sending process through the message hub, and parse the target message to obtain the message hub identifier of the receiving process; Step N: Traverse the publicly shared list of message hubs, determine the target message hub of the receiving process corresponding to the message hub identifier, and send the target message to the target message hub.

[0053] After receiving the target message uploaded by the sending process through the message hub, the target message is parsed to obtain the message hub identifier of the receiving process. Then, the target message hub of the receiving process corresponding to the message hub identifier is determined from the publicly shared message hub list. The target message is then sent to the target message hub, and the executor for processing the target message is determined.

[0054] For example, before the step of receiving the target message uploaded by the sending process through the message hub, the method further includes: Receive the message hub identifier uploaded by each process through the message hub, save the message hub identifier in the message hub list, and publicly share the message hub list.

[0055] This embodiment provides a method for constructing a list of message hubs.

[0056] The system registers the message hub by receiving the message hub identifier uploaded by each process through the message hub, saving the message hub identifier in the message hub list, and publicly sharing the message hub list between the process and the message bus.

[0057] For example, after the step of traversing the publicly shared list of message hubs, the method further includes: If the target message hub corresponding to the message hub identifier is not found in the message hub list, then wait for the target receiving process with the message hub identifier to be created. After receiving the message hub identifier uploaded by the target receiving process and saving it to the message hub list, execute the step of traversing the publicly shared message hub list.

[0058] In this embodiment, a method for decoupling the message sending process from the message receiving process is provided.

[0059] If the target message hub corresponding to the message hub identifier is not found in the message hub list, it means that the target receiving process with the message hub identifier has not yet been created. Therefore, it is necessary to wait until the target receiving process with the message hub identifier is created, and after receiving the message hub identifier uploaded by the target receiving process and saving it to the message hub list, and completing the registration of the target message hub, then the publicly shared new message hub list is re-traversed, and the target message is sent to the newly created target message hub. Thus, sending messages does not depend on the conditions, timing, attributes, etc. of receiving messages, and conversely, receiving messages does not depend on the conditions, timing, attributes, etc. of sending messages, decoupling the message sending process and the message receiving process.

[0060] Reference Figure 7From step 1 to step 11, after ClientProcess A sends a Message, it does not find a corresponding process to communicate with. Communication between ClientProcess A and ClientProcess B will only begin after ClientProcess B starts up and registers MessageHub with MessageBus in step 12. Inter-process communication is only completed in step 17 when ClientProcess B starts processing Messages from ClientProcess A.

[0061] In this embodiment, on the message bus, the receiving end process uploads a target message through a message hub, and parses the target message to obtain the message hub identifier of the receiving end process; it then traverses the publicly shared message hub list to determine the target message hub of the receiving end process corresponding to the message hub identifier, and sends the target message to the target message hub. On the message bus, the receiving end process's message hub identifier is obtained by parsing the target message received from the sending end process, the receiving end process corresponding to the message hub identifier is determined, and the target message is sent to the target message hub.

[0062] In this embodiment, as long as a process completes registration on the message bus and saves its message hub identifier to the message hub list, it can act as both a receiving process listening to messages corresponding to the executor identifier to receive data, and a sending process sending data by specifying the message hub identifier and executor identifier and carrying message parameters. This embodiment provides an inter-process communication scheme based on a multi-channel message bus distribution mechanism. It supports specifying a process to send messages and also supports a process registration mechanism based on the message bus, decoupling the sending process from the receiving process. Even when only the sending process is registered, the process will not crash due to the absence of a receiving process.

[0063] This application provides an inter-process communication method, referring to... Figure 8 In one embodiment of the inter-process communication method, the method is applied to a receiving process and includes: Step X: Receive the target message sent by the message bus through the message hub, and parse the target message to obtain the actuator identifier and message parameters; Step Y: Determine the target executor corresponding to the executor identifier through the executor list, and call the target executor to process the message parameters.

[0064] After receiving the target message from the message bus via the message hub, the process parses the target message to obtain the executor identifier and message parameters; it then iterates through the publicly shared list of executors among processes to determine the target executor corresponding to the executor identifier, and calls the target executor to process the message parameters. In one embodiment, if there is no target executor corresponding to the executor identifier, the target message is not processed.

[0065] For example, before the step of receiving the target message sent by the message bus through the message hub, the method further includes: The message hub uploads its message hub identifier to the message bus via the message hub, so that the message bus stores the message hub identifier in the message hub list.

[0066] This embodiment provides a method for constructing a list of message hubs.

[0067] The message hub uploads its message hub identifier to the message bus and saves the uploaded message hub identifier in the message hub list maintained by the message bus, thus completing the registration of the message hub and publicly sharing the message hub list between the process and the message bus.

[0068] For example, before the step of receiving the target message sent by the message bus through the message hub, the method further includes: The executor identifier of the executor is determined based on the message sent by the sending process that the executor is listening to; Save the actuator identifier of the actuator to the actuator list, and publicly share the actuator list.

[0069] This embodiment provides a method for constructing an executor list.

[0070] First, the receiving process determines the messages of the sending process that each executor is listening to. The executor identifier in the message being listened to is used as the executor identifier of the executor listening to the message. The executor identifiers of each executor are then saved to the executor list and shared publicly among the processes.

[0071] For example, multiple different executors can listen to the same executor identifier, so the sending process only needs to upload the target message with the same executor identifier to the message bus once, and can send the target message to multiple executors with the same executor identifier in multiple receiving processes at the same time, or send the target message to multiple executors with the same executor identifier in the same receiving process.

[0072] In this embodiment, the receiving process receives the target message sent by the message bus through the message hub, and parses the target message to obtain the executor identifier and message parameters; it then determines the target executor corresponding to the executor identifier through the executor list, and calls the target executor to process the message parameters. The receiving process parses the target message sent by the message bus to obtain the executor identifier and message parameters; then determines the target executor corresponding to the executor identifier, and calls the target executor to process the message parameters.

[0073] In this embodiment, as long as a process completes registration on the message bus and saves its message hub identifier to the message hub list, it can act as both a receiving process listening to messages corresponding to the executor identifier to receive data, and a sending process sending data by specifying the message hub identifier and executor identifier and carrying message parameters. This embodiment provides an inter-process communication scheme based on a multi-channel message bus distribution mechanism. It supports specifying a process to send messages and also supports a process registration mechanism based on the message bus, decoupling the sending process from the receiving process. Even when only the sending process is registered, the process will not crash due to the absence of a receiving process.

[0074] Based on the above embodiments, referring to Figure 9 This application presents an example of an inter-process communication method.

[0075] Step 1: Client Process A registers Message Hub A, which contains ModuleID A, into MessageHubList of MessageBus; Step 2: Handler_B_1 and Handler_B_2 in Client Process B are registered in MessageHub B; Step 3: Client Process B registers Message Hub B containing ModuleID B into MessageHubList of MessageBus; it should be noted that the execution is basically in the order of step 2 first and then step 3 to prevent the latest registered handler from not being found. In one embodiment, it can also be set to register the handler and respond at any time. Step 4: Client Process A creates a Message and specifies the receiving ModuleID as ModuleID B. This ModuleID is used to find the corresponding MessageHub in the Message Bus's MessageHubList. It also specifies the MessageID to process this Message as MessageID1. This MessageID is used to find the corresponding Handler in the found MessageHub. Step 5: Client Process A starts the MessageHandle Thread in the Message Bus through MessageHub A to process the Message messages sent by Client Process A.

[0076] Step 6: This involves two steps: 1) The Message Handle Thread in Message Bus searches through MessageHubList and finds MessageHub B in Client Process A that needs to be processed by MessageHub with ModuleID B.

[0077] 2) After finding MessageHub B, MessageHub B iterates through its HandlerList and finds the Handler_B_1 of MessageID 1 in Client Process A that needs to be processed by MessageHub B.

[0078] Step 7: By executing Handler_B_1 found in MessageHub B in Step 6, Handler_B_1 defined in Client Process B will be invoked. Handler_B_1 will then process the Param information received from ClientProcess A, thereby completing the communication between processes A and B.

[0079] Unlike MessageHubList, which is a publicly transparent shared list between processes and the message bus, and HandlerList, which is a publicly transparent shared list between processes, ModuleId and messageId are shared between processes and the bus.

[0080] Alternatively, ClientProcess B can also create a Message based on ModuleID A and MessageID3. As long as ClientProcess A registers a Handler based on MessageID3, ClientProcess B can send a message to ClientProcess A. In turn, the Handler of ClientProcess A will process the Message of ClientProcess B, thus realizing bidirectional communication between threads ClientProcess A and ClientProcess B.

[0081] This application example provides an inter-process communication scheme based on a multiplexed message bus distribution mechanism. It supports sending messages by a specified process and also supports a process registration mechanism based on the message bus, decoupling the sending and receiving processes. Even when only the sending process is registered, the process will not crash due to the absence of a receiving process.

[0082] Furthermore, this application embodiment also provides an inter-process communication device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the inter-process communication method as described above.

[0083] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the inter-process communication method described above.

[0084] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0085] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0086] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method of inter-process communication, characterized by, The method is applied to the sending process and includes: Create a message by specifying the message hub identifier of the receiving process through a publicly shared list of message hubs, specifying the executor identifier of the receiving process through a publicly shared list of executors, and specifying the message parameters to be carried, and obtain the target message; The target message is uploaded to the message bus via the message hub, and then forwarded to the receiving process via the message bus. The method further includes: If multiple message hub identifiers are specified in the target message, the target message is forwarded to multiple receiving processes corresponding to the multiple message hub identifiers through the message bus; If the message hub identifier is not specified in the target message, the target message is forwarded to all receiving processes corresponding to the message hub list via the message bus.

2. An inter-process communication method, characterized by, The method is applied to a message bus and includes: The receiving end process receives the target message uploaded through the message hub and parses the target message to obtain the message hub identifier of the receiving end process. Traverse the publicly shared list of message hubs, determine the target message hub of the receiving process corresponding to the message hub identifier, and send the target message to the target message hub. Following the step of traversing the publicly shared list of message hubs, the method further includes: If the target message hub corresponding to the message hub identifier is not found in the message hub list, then wait for the target receiving process with the message hub identifier to be created. After receiving the message hub identifier uploaded by the target receiving process and saving it to the message hub list, execute the step of traversing the publicly shared message hub list.

3. The inter-process communication method of claim 2, wherein, Before the step of receiving the target message uploaded by the sending process through the message hub, the method further includes: Receive the message hub identifier uploaded by each process through the message hub, save the message hub identifier in the message hub list, and publicly share the message hub list.

4. An inter-process communication method, characterized in that, The method is applied to the receiving process and includes: The message hub receives the target message sent by the message bus and parses the target message to obtain the actuator identifier and message parameters. The target executor corresponding to the executor identifier is determined by the executor list, and the target executor is invoked to process the message parameters; Before the step of receiving the target message sent from the message bus through the message hub, the method further includes: The executor identifier of the executor is determined based on the message sent by the sending process that the executor is listening to; Save the actuator identifier of the actuator to the actuator list, and publicly share the actuator list.

5. The inter-process communication method as described in claim 4, characterized in that, Before the step of receiving the target message sent from the message bus through the message hub, the method further includes: The message hub uploads its message hub identifier to the message bus via the message hub, so that the message bus stores the message hub identifier in the message hub list.

6. An inter-process communication system, characterized in that, The system includes: A sending process that implements the inter-process communication method as described in claim 1; A message bus that implements the inter-process communication method as described in any one of claims 2 to 3; A receiving process that implements the inter-process communication method as described in any one of claims 4 to 5.

7. An inter-process communication device, characterized in that, The inter-process communication device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the inter-process communication method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the inter-process communication method as described in any one of claims 1 to 5.

Images