CN116382936A - Inter-process communication method, system, equipment and medium - Google Patents

Inter-process communication method, system, equipment and medium Download PDF

Info

Publication number
CN116382936A
CN116382936A CN202310067592.8A CN202310067592A CN116382936A CN 116382936 A CN116382936 A CN 116382936A CN 202310067592 A CN202310067592 A CN 202310067592A CN 116382936 A CN116382936 A CN 116382936A
Authority
CN
China
Prior art keywords
message
hub
target
list
inter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310067592.8A
Other languages
Chinese (zh)
Inventor
刘芳超
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Goertek Inc
Original Assignee
Goertek Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Goertek Inc filed Critical Goertek Inc
Priority to CN202310067592.8A priority Critical patent/CN116382936A/en
Publication of CN116382936A publication Critical patent/CN116382936A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

The application discloses an inter-process communication method, an inter-process communication system, inter-process communication equipment and a medium, and belongs to the technical field of inter-process communication. As long as the process finishes registration on the message bus and stores the message hub identifier of the process into the message hub list, the process can be used as a receiving end process to monitor the message corresponding to the executor identifier, so as to realize the data receiving; and the method can also be used as a transmitting end process to realize data transmission by designating a message hub identifier and an actuator identifier and carrying message parameters. In the present application, an inter-process communication scheme based on a multi-way message bus distribution mechanism is provided. The message sending process is supported to send the message, and a process registration mechanism based on a message bus is supported to decouple the message sending process from the message receiving process, so that the problem of process crash caused by no registration of the message receiving process can be avoided even when only the message sending process registers.

Description

Inter-process communication method, system, equipment and medium
Technical Field
The present invention relates to the field of inter-process communication technologies, 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
Inter-process communication (IPC) in the Linux platform is mainly used for scheduling processes, sharing inter-process resources and transferring data. Based on the above inter-process communication requirements, the Linux platform provides a primitive-based solution for developers. The method in these solutions mainly comprises: signals, pipes, named pipes, sockets, semaphores, shared memory, and message queues.
When simple data transfer and event notification are carried out between processes, a communication mechanism of event callback is generally adopted. The communication mechanism based on the event callback realizes the inter-process communication mode, and is simple and easy to realize. However, when the specific application event Callback performs inter-process communication, an abnormal problem that a call back Object is a null pointer exists, so that the call process crashes, and the normal function of the call process is affected.
Disclosure of Invention
The main objective of the present 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, which are aimed at solving the technical problem of process crash caused by no message receiving process in the prior art.
In order to achieve the above object, the present application provides an inter-process communication method, where the method is applied to a sender process, and includes:
creating a message, designating a message hub identifier of a receiving end process through a public shared message hub list, designating an actuator identifier of the receiving end process through a public shared actuator list, and designating carried message parameters to obtain a target message;
uploading the target message to a message bus through a message hub, and forwarding the target message to a receiving end process through the message bus.
In an embodiment, the method further comprises:
if a plurality of message hub identifications are designated in the target message, forwarding the target message to a plurality of receiving end processes corresponding to the message hub identifications through the message bus;
if the message hub identification is not specified in the target message, forwarding the target message to all receiving end processes corresponding to a message hub list through the message bus.
To achieve the above object, the present application provides an inter-process communication method, which is applied to a message bus, including:
Receiving a target message uploaded by a transmitting end process through a message hub, and analyzing the target message to obtain a message hub identification of a receiving end process;
traversing a public shared message hub list, determining a target message hub of a corresponding receiving end process of the message hub identification, and transmitting the target message to the target message hub.
In an embodiment, before the step of receiving the target message uploaded by the sender process through the message hub, the method further includes:
receiving a message hub identifier of the message hub uploaded by each process through the message hub, storing the message hub identifier in a message hub list, and carrying out public sharing on the message hub list.
In one embodiment, after the step of traversing the publicly shared message hub list, the method further comprises:
if the target message hub of the receiving end process corresponding to the message hub identification is not found in the message hub list, waiting for the target receiving end process with the message hub identification to be created, and executing the step of traversing the publicly shared message hub list after receiving the message hub identification uploaded by the target receiving end process and saving the message hub identification to the message hub list.
In order to achieve the above object, the present application provides an inter-process communication method, where the method is applied to a receiving end process, and includes:
receiving a target message issued by a message bus through a message hub, and analyzing the target message to obtain an executor identifier and message parameters;
and determining a target executor corresponding to the executor identifier through an executor list, and calling the target executor to process the message parameters.
In an embodiment, before the step of receiving the target message sent by the message bus through the message hub, the method further includes:
and uploading the message hub identification of the message hub to a message bus through the message hub, so that the message bus stores the message hub identification of the message hub in a message hub list.
In an embodiment, before the step of receiving the target message sent by the message bus through the message hub, the method further includes:
determining an actuator identification of an actuator according to a message sent by a sender process to be monitored by the actuator;
and storing the actuator identification of the actuator to an actuator list, and carrying out public sharing on the actuator list.
The present application also provides an inter-process communication system, the system comprising:
a transmitting end process for realizing the inter-process communication method as described above;
a message bus implementing the interprocess communication method as described above;
a receiving end process implementing the inter-process communication method as described above.
The present application also provides an inter-process communication device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, which when executed by the processor, performs the steps of the inter-process communication method as described above.
The present application also provides a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the steps of the inter-process communication method described above.
The application discloses an inter-process communication method, an inter-process communication system, inter-process communication equipment and a computer readable storage medium, wherein a message is created in a transmitting end process, a message hub identifier of a receiving end process is designated through a public shared message hub list, an actuator identifier of the receiving end process is designated through a public shared actuator list, and carried message parameters are designated to obtain a target message; uploading the target message to a message bus through a message hub, and forwarding the target message to a receiving end process through the message bus. Receiving a target message uploaded by a transmitting end process through a message hub on a message bus, and analyzing the target message to obtain a message hub identification of a receiving end process; traversing a public shared message hub list, determining a target message hub of a corresponding receiving end process of the message hub identification, and transmitting the target message to the target message hub. Receiving a target message issued by a message bus through a message hub at a receiving end process, and analyzing the target message to obtain an executor identifier and message parameters; and determining a target executor corresponding to the executor identifier through an executor list, and calling the target executor to process the message parameters.
In the application, a sending end process obtains a target message by designating a message hub identifier and an actuator identifier and carrying message parameters; and forwarding the target message to the receiving end process through the message bus. And analyzing the target message received from the sending end process in the message bus to obtain the message hub identification of the receiving end process, determining the receiving end process corresponding to the message hub identification, and transmitting the target message to the target message hub. Analyzing a target message issued by a message bus at a receiving end process to obtain an executor identifier and message parameters; and determining the target executor corresponding to the executor identifier, and calling the target executor to process the message parameters.
In the application, as long as the process completes registration on the message bus and stores the message hub identifier of the process into the message hub list, the process can be used as a receiving end process to monitor the message corresponding to the executor identifier, so that the data is received; and the method can also be used as a transmitting end process to realize data transmission by designating a message hub identifier and an actuator identifier and carrying message parameters. In the present application, an inter-process communication scheme based on a multi-way message bus distribution mechanism is provided. The message sending process is supported to send the message, and a process registration mechanism based on a message bus is supported to decouple the message sending process from the message receiving process, so that the problem of process crash caused by no registration of the message receiving process can be avoided even when only the message sending process registers.
Drawings
FIG. 1 is a schematic diagram of an operating device of a hardware operating environment according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a communication mechanism based on event callbacks;
FIG. 3 is a schematic diagram of a communication model based on a multi-channel message bus distribution mechanism according to an embodiment of an inter-process communication method according to the embodiments of the present application;
FIG. 4 is a schematic diagram of a system architecture of an embodiment of an inter-process communication method according to an embodiment of the present application;
FIG. 5 is a flow chart of an embodiment of an inter-process communication method according to an embodiment of the present application;
FIG. 6 is a flow chart of another embodiment of an inter-process communication method according to an embodiment of the present application;
FIG. 7 is a process decoupling diagram illustrating an embodiment of an inter-process communication method according to an embodiment of the present application;
FIG. 8 is a flow chart of another embodiment of an inter-process communication method according to an embodiment of the present application;
fig. 9 is a schematic diagram illustrating an inter-module communication operation of an application example of an inter-process communication method according to an embodiment of the present application.
The realization, functional characteristics and advantages of the present application will be further described with reference to the embodiments, referring to the attached drawings.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.
Referring to fig. 1, fig. 1 is a schematic diagram of an operating device of a hardware operating environment according to an embodiment of the present application.
As shown in fig. 1, the operation device may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a WIreless interface (e.g., a WIreless-FIdelity (WI-FI) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) Memory or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.
It will be appreciated by those skilled in the art that the structure shown in fig. 1 is not limiting of the operating device and may include more or fewer components than shown, or certain components may be combined, or a different arrangement of components.
As shown in fig. 1, an operating system, a data storage module, a network communication module, a user interface module, and a computer program may be included in the memory 1005 as one type of storage medium.
In the operating device shown in fig. 1, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with a user; the processor 1001, the memory 1005 in the operation device of the present application may be provided in an operation device that calls a computer program stored in the memory 1005 through the processor 1001 and performs the following operations:
creating a message, designating a message hub identifier of a receiving end process through a public shared message hub list, designating an actuator identifier of the receiving end process through a public shared actuator list, and designating carried message parameters to obtain a target message;
uploading the target message to a message bus through a message hub, and forwarding the target message to a receiving end process through the message bus.
In an embodiment, the processor 1001 may call a computer program stored in the memory 1005, and further perform the following operations:
if a plurality of message hub identifications are designated in the target message, forwarding the target message to a plurality of receiving end processes corresponding to the message hub identifications through the message bus;
if the message hub identification is not specified in the target message, forwarding the target message to all receiving end processes corresponding to a message hub list through the message bus.
In an embodiment, the processor 1001 may call a computer program stored in the memory 1005, and further perform the following operations:
receiving a target message uploaded by a transmitting end process through a message hub, and analyzing the target message to obtain a message hub identification of a receiving end process;
traversing a public shared message hub list, determining a target message hub of a corresponding receiving end process of the message hub identification, and transmitting the target message to the target message hub.
In an embodiment, the processor 1001 may call 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 sender process through the message hub, the method further comprises the following steps:
receiving a message hub identifier of the message hub uploaded by each process through the message hub, storing the message hub identifier in a message hub list, and carrying out public sharing on the message hub list.
In an embodiment, the processor 1001 may call a computer program stored in the memory 1005, and further perform the following operations:
after the step of traversing the publicly shared message hub list, further comprises:
if the target message hub of the receiving end process corresponding to the message hub identification is not found in the message hub list, waiting for the target receiving end process with the message hub identification to be created, and executing the step of traversing the publicly shared message hub list after receiving the message hub identification uploaded by the target receiving end process and saving the message hub identification to the message hub list.
In an embodiment, the processor 1001 may call a computer program stored in the memory 1005, and further perform the following operations:
receiving a target message issued by a message bus through a message hub, and analyzing the target message to obtain an executor identifier and message parameters;
And determining a target executor corresponding to the executor identifier through an executor list, and calling the target executor to process the message parameters.
In an embodiment, the processor 1001 may call a computer program stored in the memory 1005, and further perform the following operations:
before the step of receiving the target message sent by the message bus through the message hub, the method further comprises the following steps:
and uploading the message hub identification of the message hub to a message bus through the message hub, so that the message bus stores the message hub identification of the message hub in a message hub list.
In an embodiment, the processor 1001 may call a computer program stored in the memory 1005, and further perform the following operations:
before the step of receiving the target message sent by the message bus through the message hub, the method further comprises the following steps:
determining an actuator identification of an actuator according to a message sent by a sender process to be monitored by the actuator;
and storing the actuator identification of the actuator to an actuator list, and carrying out public sharing on the actuator list.
Referring to FIG. 2, in the event Callback-based communication mechanism, a CallBack Object is created in Progess2 and registered in the Factory Object in Process 2, and added to the Factory Object in Callback Object List. The call back Object created in Progess2 inherits from the call back component interface class in Progess1, so that when the factor Object in Progess2 processes the function, the call back component instance Object in Callback Object List is sequentially obtained, and then finally called into the call back function in the call back component Object in the call back component instance Object in Progess 1.
For the Callback Object in Progress1 shown in fig. 2, the Callback Object will register its pointer to Progress2, i.e., add the pointer corresponding to the Callback Object to Callback Object List in the factor Object. However, when the Function in the factor Object obtains the Callback Object from Callback Object List and executes Callback Function, if the Callback Object in the Process1 is destroyed, a null pointer exception is generated when the Function in the Process 2 is executed, resulting in a crash of the Process 2, which cannot work.
Referring to fig. 3, an embodiment of the present application provides an inter-process communication system, the system including:
a transmitting end process for realizing an inter-process communication method as described below;
a message bus implementing an interprocess communication method as described below;
a receiving end process implementing an inter-process communication method as described below.
The method is characterized in that the method is equivalent to taking a message bus as a server and a receiving end process and a transmitting end process as clients; wherein 1) Message Bus is also a process that needs to be started before a process relying on it for communication; 2) After the Process A/B/C is started, the Process A/B/C needs to be registered on a Message Bus. Each Process of the Process A/B/C can be used as a sender (S) or a receiver (R); 3) Process a registers for listening to the message_id_1, process B registers for listening to the message_id_2, and Process C registers for listening to the message_id_3; 4) Any one of the processes A/B/C sends a Message of the message_ID_1 type, which is received by the Process A. In the same way, any Message of the message_id_2 type or the message_id_3 type sent by the Process will be received by the Process B or the Process C.
Referring to fig. 4, the Message Bus based on the present solution mainly consists of four parts, namely a Message hub manager, a Message hub, a Message and a Message-Param.
The message hubmanager is mainly used for creating a message hub by a regeister and unregister communication process, and maintaining a message hub list. Each process that needs to use a message bus to communicate needs to create a message hub object that uses a ModuleId (message hub identification) as an identification, and register it in the message bus. Wherein the MessageHubList is a publicly transparent shared list between the process and the message bus. Wherein, each communication process has only one Message Hub, and the sending and receiving of the messages are realized through the only one Message Hub.
The MessageHub is mainly used for registering and deregistering a Handler, and the Handler is used for processing the received message of the specific ModuleId and the messageId (the identifier of the executor); message of creating Message specific Message id; sending a Message to a created Message of a specific Messagehub object sendMessage based on ModuleID; the process transmits data and receives data by a message hub. And maintaining a HandlerList. Wherein, handlerList is a public transparent shared list among various processes.
The Message is mainly used for containing data to be communicated, namely Message-Param, and a Message Id for uniquely identifying the Message, and after receiving the Message, other processes process the Message by matching the Message Id to a designated handler.
The Message-Param mainly comprises a function getParamX for acquiring each parameter, and the function getParamX is used for acquiring specific information contained in the Message-Param.
In this embodiment, as long as the process completes registration on the message bus and stores the message hub identifier of the process in the message hub list, the process can be used as a receiving end process to monitor the message corresponding to the executor identifier, so as to realize data reception; and the method can also be used as a transmitting end process to realize data transmission by designating a message hub identifier and an actuator identifier and carrying message parameters. In this embodiment, an inter-process communication scheme based on a multi-channel message bus distribution mechanism is provided. The message sending process is supported to send the message, and a process registration mechanism based on a message bus is supported to decouple the message sending process from the message receiving process, so that the problem of process crash caused by no registration of the message receiving process can be avoided even when only the message sending process registers.
An embodiment of the present application provides an inter-process communication method, referring to fig. 5, in an embodiment of the inter-process communication method, the method is applied to a sender process, and includes:
step A, creating a message, designating a message hub identifier of a receiving end process through a public shared message hub list, designating an executor identifier of the receiving end process through a public shared executor list, and designating carried message parameters to obtain a target message;
in this embodiment, after the message is created, a message hub list of a message hub list which is shared between a process and a message bus in a public transparent manner is determined, a message hub identifier of a receiving end process is specified in the message hub list, and the message hub of the receiving end process is indicated by the message hub identifier. Determining a HandlerList executor list which is publicly and transparently shared among all the processes, designating an executor identification of a receiving end process in the executor list, and indicating an executor used for processing a target message in the receiving end process through the executor identification. After the message hub identifier and the executor identifier are specified, message parameters to be carried in the message are specified to obtain a target message, so that the message parameters in the target message can be determined to be received by the corresponding receiving end process of the message hub identifier and processed by the corresponding executor of the corresponding receiving end process. The appointed received ModuleID may be a message hub identifier of the sender process itself, so as to implement a function similar to loop detection.
And step B, uploading the target message to a message bus through a message hub, and forwarding the target message to a receiving end process through the message bus.
Referring to fig. 3, after obtaining the target message, the sending end process uploads the target message to the message bus through the message hub, forwards the target message to the receiving end process through the message bus, and further issues the target message to the receiving end process to monitor the message parameters in the target message processed by the executor identified by the executor in the target message. Therefore, the transmitting end process realizes communication between the transmitting end process and the receiving end process by calling the method in the receiving end process.
Illustratively, the method further comprises:
if a plurality of message hub identifications are designated in the target message, forwarding the target message to a plurality of receiving end processes corresponding to the message hub identifications through the message bus;
if the message hub identification is not specified in the target message, forwarding the target message to all receiving end processes corresponding to a message hub list through the message bus.
If the sender process designates a plurality of message hub identifications when defining the target message, the target message is forwarded to a plurality of receiver processes corresponding to the message hub identifications in the message hub list through a message bus, and the sender process communicates with the plurality of receiver processes registered in the message hub list.
If the sender process does not assign the message hub identification when defining the target message, forwarding the target message to all corresponding receiver processes in the message hub list through the message bus, and communicating between the sender process and all the receiver processes registered in the message hub list.
In this embodiment, a message is created in a sender process, a message hub identifier of a receiver process is specified by a public shared message hub list, an executor identifier of the receiver process is specified by a public shared executor list, and carried message parameters are specified, so as to obtain a target message; uploading the target message to a message bus through a message hub, and forwarding the target message to a receiving end process through the message bus. The process at the transmitting end obtains the target message by designating the message hub identifier and the actuator identifier and carrying the message parameters; and forwarding the target message to the receiving end process through the message bus.
Therefore, as long as the process completes registration on the message bus and stores the message hub identifier of the process into the message hub list, the process can be used as a receiving end process to monitor the message corresponding to the executor identifier, and data receiving is realized; and the method can also be used as a transmitting end process to realize data transmission by designating a message hub identifier and an actuator identifier and carrying message parameters. In this embodiment, an inter-process communication scheme based on a multi-channel message bus distribution mechanism is provided, which supports a designated process to send a message, and supports a process registration mechanism based on a message bus, so that a sending message process and a receiving message process are decoupled, and even when only the sending message process registers, the problem of process crash caused by no registration of the receiving message process is avoided.
An embodiment of the present application provides an inter-process communication method, referring to fig. 6, in an embodiment of the inter-process communication method, the method is applied to a message bus, and includes:
step M: receiving a target message uploaded by a transmitting end process through a message hub, and analyzing the target message to obtain a message hub identification of a receiving end process;
step N: traversing a public shared message hub list, determining a target message hub of a corresponding receiving end process of the message hub identification, and transmitting the target message to the target message hub.
After receiving the target message uploaded by the sender process through the message hub, analyzing the target message to obtain the message hub identification of the receiver process, determining the target message hub of the receiver process corresponding to the message hub identification in the public shared message hub list, and transmitting the target message to the target message hub to further determine an executor for processing the target message.
Illustratively, before the step of receiving the target message uploaded by the sender process through the message hub, the method further includes:
receiving a message hub identifier of the message hub uploaded by each process through the message hub, storing the message hub identifier in a message hub list, and carrying out public sharing on the message hub list.
In this embodiment, a method of constructing a message hub list is provided.
The message hub identification of the message hub uploaded by each process through the message hub is received, the message hub identification is stored in a message hub list, the registration of the message hub is completed, and the message hub list is publicly shared between the processes and the message bus.
Illustratively, after the step of traversing the publicly shared message hub list, further comprises:
if the target message hub of the receiving end process corresponding to the message hub identification is not found in the message hub list, waiting for the target receiving end process with the message hub identification to be created, and executing the step of traversing the publicly shared message hub list after receiving the message hub identification uploaded by the target receiving end process and saving the message hub identification to the message hub list.
In this embodiment, a method of decoupling a sending message process from a receiving message process is provided.
If the target message hub of the receiving end process corresponding to the message hub identification is not found in the message hub list, the target receiving end process with the message hub identification is not created, so that the target receiving end process with the message hub identification needs to wait until the target receiving end process with the message hub identification is created, the message hub identification uploaded by the target receiving end process is received and stored in the message hub list, and after the registration of the target message hub is completed, the new message hub list which is publicly shared is traversed again, and the target message is issued to the newly created target message hub. Thus, the sending message is independent of the condition, the time, the attribute, etc. of the receiving message, whereas the receiving message is independent of the condition, the time, the attribute, etc. of the sending message, and the sending message process and the receiving message process are decoupled.
Referring to fig. 7, after the Message is sent from step 1 to step 11,ClientProcess A, communication is not performed until the corresponding Process is not matched, communication between the Client Process a and the Client Process B is performed after the Message hub is registered to the Message bus after the start of step 12,Client Process B, and communication between the processes is not completed until the Process of the Client Process a starts to be processed in step 17,Client Process B.
In this embodiment, in the message bus, a target message uploaded by a sender process through a message hub is received, and the target message is parsed to obtain a message hub identifier of a receiver process; traversing a public shared message hub list, determining a target message hub of a corresponding receiving end process of the message hub identification, and transmitting the target message to the target message hub. And analyzing the target message received from the sending end process in the message bus to obtain the message hub identification of the receiving end process, determining the receiving end process corresponding to the message hub identification, and transmitting the target message to the target message hub.
In this embodiment, as long as the process completes registration on the message bus and stores the message hub identifier of the process in the message hub list, the process can be used as a receiving end process to monitor the message corresponding to the executor identifier, so as to realize data reception; and the method can also be used as a transmitting end process to realize data transmission by designating a message hub identifier and an actuator identifier and carrying message parameters. In this embodiment, an inter-process communication scheme based on a multi-channel message bus distribution mechanism is provided. The message sending process is supported to send the message, and a process registration mechanism based on a message bus is supported to decouple the message sending process from the message receiving process, so that the problem of process crash caused by no registration of the message receiving process can be avoided even when only the message sending process registers.
An embodiment of the present application provides an inter-process communication method, referring to fig. 8, in an embodiment of the inter-process communication method, the method is applied to a receiving end process, and includes:
step X: receiving a target message issued by a message bus through a message hub, and analyzing the target message to obtain an executor identifier and message parameters;
step Y: and determining a target executor corresponding to the executor identifier through an executor list, and calling the target executor to process the message parameters.
After receiving a target message issued by a message bus through a message hub, analyzing the target message to obtain an executor identifier and message parameters; traversing the query to disclose a shared executor list among the processes, determining that the executor identifies a corresponding target executor, and invoking the target executor to process the message parameters. In one embodiment, if no actuator identifies a corresponding target actuator, then the target message is not processed.
Illustratively, before the step of receiving the target message sent by the message bus through the message hub, the method further includes:
and uploading the message hub identification of the message hub to a message bus through the message hub, so that the message bus stores the message hub identification of the message hub in a message hub list.
In this embodiment, a method of constructing a message hub list is provided.
Uploading the message hub identification of the message hub to the message bus through the message hub, storing the uploaded message hub identification in a message hub list maintained by the message bus, completing registration of the message hub, and carrying out public sharing on the message hub list between the process and the message bus.
Illustratively, before the step of receiving the target message sent by the message bus through the message hub, the method further includes:
determining an actuator identification of an actuator according to a message sent by a sender process to be monitored by the actuator;
and storing the actuator identification of the actuator to an actuator list, and carrying out public sharing on the actuator list.
In this embodiment, a method of building an actuator list is provided.
Firstly, determining the information of a sender process monitored by each actuator in a receiver process, taking the actuator identification in the monitored information as the actuator identification of the actuator for monitoring the information, storing the actuator identification of each actuator into an actuator list, and carrying out public sharing among the processes.
For example, multiple different executors may monitor the same executor identifier, so that the sending end process may only need to upload the target message with the same executor identifier to the message bus once, so that the target message may be sent to multiple executors with the same executor identifier in multiple receiving end processes at the same time, or the target message may be sent to multiple executors with the same executor identifier in the same receiving end process.
In the embodiment, in a receiving end process, a target message issued by a message bus is received through a message hub, and the target message is analyzed to obtain an actuator identifier and a message parameter; and determining a target executor corresponding to the executor identifier through an executor list, and calling the target executor to process the message parameters. Analyzing a target message issued by a message bus at a receiving end process to obtain an executor identifier and message parameters; and determining the target executor corresponding to the executor identifier, and calling the target executor to process the message parameters.
In this embodiment, as long as the process completes registration on the message bus and stores the message hub identifier of the process in the message hub list, the process can be used as a receiving end process to monitor the message corresponding to the executor identifier, so as to realize data reception; and the method can also be used as a transmitting end process to realize data transmission by designating a message hub identifier and an actuator identifier and carrying message parameters. In this embodiment, an inter-process communication scheme based on a multi-channel message bus distribution mechanism is provided. The message sending process is supported to send the message, and a process registration mechanism based on a message bus is supported to decouple the message sending process from the message receiving process, so that the problem of process crash caused by no registration of the message receiving process can be avoided even when only the message sending process registers.
Based on the above embodiments, referring to fig. 9, an application example of an inter-process communication method of the present application is proposed.
Step 1: the Client Process A registers the Message Hub A containing the ModuleID A into the Message HubList of the Message Bus;
step 2: handler_B_1 in Client Process B, handler_B_2 registers with Messagehub B;
step 3: the Client Process B registers the Message Hub containing the ModuleID B in the Message Hub list of the Message Bus, and it should be noted that the Process B is basically executed according to the sequence of the steps 2 and 3 to prevent the newest registered handler from being searched, and in an embodiment, the Process B can also be set as a mode of registering the handler at any time and responding at any time;
step 4: the Client Process A creates a Message, designates the received ModuleID as ModuleID B, and the ModuleID is used for searching a corresponding Messagehub in a MessageHubList of the Message Bus, and designates a MessageID for processing the Message as MessageID1, wherein the MessageID is used for searching a corresponding Handler in the searched Messagehub;
step 5: the Client Process A starts a Message Handle Thread thread in the Message Bus through the Message hub A to Process the Message sent in the Client Process A.
Step 6: the method comprises the following two steps:
1) The Message Handle Thread thread in the Message Bus searches the Message hub list through traversing, and the Message hub which needs to be processed by the Message in the Client Process A is the Message hub B of the MoudeID B.
2) After finding the Messagehub B, the Messagehub B traverses and searches the HandlerList in the Messagehub B, and finds the Handler_B_1 of the Message in the Client Process A, which needs to be processed by the Messagehub B, of the MessageID 1.
Step 7: by executing the handler_b_1 in MessageMessageHub B found in step 6, the handler_b_1 defined in the Client Process B is called, and the handler_b_1 performs corresponding processing through the Param information in the Message received from the Client Process a. Thereby completing the communication between processes a and B.
Wherein, unlike the messagehubList which is a public transparent shared list between the process and the message bus, the HandlerList which is a public transparent shared list between each process, the Moduleid and the messageId are shared between the process and the bus.
In addition, the Client Process B may create a Message based on the MoudleID a and the Message id3, and as long as the Client Process a registers a Handler based on the Message id3, the Client Process B may send a Message to the Client Process a, so that the Handler of the Client Process a may Process the Message of the Client Process B, thereby implementing bidirectional communication between the threads of the Client Process a and the Client Process B.
In this application example, an inter-process communication scheme based on a multi-way message bus distribution mechanism is provided. The message sending process is supported to send the message, and a process registration mechanism based on a message bus is supported to decouple the message sending process from the message receiving process, so that the problem of process crash caused by no registration of the message receiving process can be avoided even when only the message sending process registers.
In addition, the embodiment of the application also provides an inter-process communication device, which comprises: a memory, a processor, and a computer program stored on the memory and executable on the processor, which when executed by the processor, performs the steps of the inter-process communication method as described above.
Furthermore, embodiments of the present application also provide a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the inter-process communication method as described above.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
From the above description of embodiments, it will be clear to a person skilled in the art that the above embodiment method may be implemented by means of software plus a necessary general hardware platform, but may of course also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) as described above, including several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method described in the embodiments of the present application.
The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the claims, and all equivalent structures or equivalent processes using the descriptions and drawings of the present application, or direct or indirect application in other related technical fields are included in the scope of the claims of the present application.

Claims (11)

1. An inter-process communication method, wherein the method is applied to a sender process, and comprises the following steps:
Creating a message, designating a message hub identifier of a receiving end process through a public shared message hub list, designating an actuator identifier of the receiving end process through a public shared actuator list, and designating carried message parameters to obtain a target message;
uploading the target message to a message bus through a message hub, and forwarding the target message to a receiving end process through the message bus.
2. The inter-process communication method of claim 1, wherein the method further comprises:
if a plurality of message hub identifications are designated in the target message, forwarding the target message to a plurality of receiving end processes corresponding to the message hub identifications through the message bus;
if the message hub identification is not specified in the target message, forwarding the target message to all receiving end processes corresponding to a message hub list through the message bus.
3. An inter-process communication method, the method being applied to a message bus, comprising:
receiving a target message uploaded by a transmitting end process through a message hub, and analyzing the target message to obtain a message hub identification of a receiving end process;
Traversing a public shared message hub list, determining a target message hub of a corresponding receiving end process of the message hub identification, and transmitting the target message to the target message hub.
4. The method for inter-process communication as recited in claim 3, wherein prior to the step of receiving the target message uploaded by the sender process through the message hub, further comprising:
receiving a message hub identifier of the message hub uploaded by each process through the message hub, storing the message hub identifier in a message hub list, and carrying out public sharing on the message hub list.
5. The method of interprocess communication of claim 3 wherein after the step of traversing the publicly shared message hub list, further comprising:
if the target message hub of the receiving end process corresponding to the message hub identification is not found in the message hub list, waiting for the target receiving end process with the message hub identification to be created, and executing the step of traversing the publicly shared message hub list after receiving the message hub identification uploaded by the target receiving end process and saving the message hub identification to the message hub list.
6. An inter-process communication method, wherein the method is applied to a receiving end process, and comprises:
receiving a target message issued by a message bus through a message hub, and analyzing the target message to obtain an executor identifier and message parameters;
and determining a target executor corresponding to the executor identifier through an executor list, and calling the target executor to process the message parameters.
7. The method of interprocess communication of claim 6 wherein prior to the step of receiving the target message delivered by the message bus via the message hub, further comprising:
and uploading the message hub identification of the message hub to a message bus through the message hub, so that the message bus stores the message hub identification of the message hub in a message hub list.
8. The method of interprocess communication of claim 6 wherein prior to the step of receiving the target message delivered by the message bus via the message hub, further comprising:
determining an actuator identification of an actuator according to a message sent by a sender process to be monitored by the actuator;
and storing the actuator identification of the actuator to an actuator list, and carrying out public sharing on the actuator list.
9. An interprocess communication system, wherein the system comprises:
a sender process implementing the inter-process communication method of claims 1 to 2;
message bus implementing an inter-process communication method according to claims 3 to 5;
a receiving end process implementing the inter-process communication method as claimed in claims 6 to 8.
10. An inter-process communication device, the inter-process communication device comprising: memory, a processor, and a computer program stored on the memory and executable on the processor, which when executed by the processor, performs the steps of the inter-process communication method as claimed in any one of claims 1 to 8.
11. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the inter-process communication method according to any of claims 1 to 8.
CN202310067592.8A 2023-01-16 2023-01-16 Inter-process communication method, system, equipment and medium Pending CN116382936A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310067592.8A CN116382936A (en) 2023-01-16 2023-01-16 Inter-process communication method, system, equipment and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310067592.8A CN116382936A (en) 2023-01-16 2023-01-16 Inter-process communication method, system, equipment and medium

Publications (1)

Publication Number Publication Date
CN116382936A true CN116382936A (en) 2023-07-04

Family

ID=86975756

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310067592.8A Pending CN116382936A (en) 2023-01-16 2023-01-16 Inter-process communication method, system, equipment and medium

Country Status (1)

Country Link
CN (1) CN116382936A (en)

Similar Documents

Publication Publication Date Title
KR102415845B1 (en) Internet of Things Resource Subscription Methods, Devices, and Systems
US8584136B2 (en) Context-aware request dispatching in clustered environments
CN109981716B (en) Micro-service calling method and device
US6868544B2 (en) Method and system for general-purpose interactive notifications
US8139596B2 (en) Communicating prioritized messages to a destination queue from multiple source queues using source-queue-specific priority values
US10454795B1 (en) Intermediate batch service for serverless computing environment metrics
US9274857B2 (en) Method and system for detecting work completion in loosely coupled components
US20110238760A1 (en) Systems and methods for identifying contacts as users of a multi-tenant database and application system
CN112787999B (en) Cross-chain calling method, device, system and computer readable storage medium
CN112313627B (en) Mapping mechanism of event to serverless function workflow instance
US8694462B2 (en) Scale-out system to acquire event data
JP2015527658A (en) Method, system, and computer program product for asynchronous message sequencing in a distributed parallel environment
CN112688816B (en) Rule-based action triggering method and system in provider network
CN107819855B (en) Message distribution method and device
CN116382936A (en) Inter-process communication method, system, equipment and medium
CN115334155A (en) Message queue agent method and device
CN115361348A (en) Method for communicating with web browser performed by data acquisition device
US8739166B2 (en) Progress-driven progress information in a service-oriented architecture
CN111726417B (en) Delay control method, device, server and storage medium
US20030236922A1 (en) Data propagation in an activity service
CN113986516A (en) Distributed task scheduling system based on Hongming system
US7757235B2 (en) Trigger support for a bi-directional broker
KR20160077432A (en) Event managing system of steel process middleware
US8549537B2 (en) Middleware bridge system and method
US7725902B2 (en) Finer grained point-to-point event propagation

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination