Inter-process communication method and device, equipment and medium

Abstract

The invention relates to an inter-process communication method and device, equipment and a medium. The method comprises the following steps: determining the length type of a communication message to be transmitted through a client process; under the condition that the length type of the communication message is a first type of message of which the length is not less than a preset length value, applying for a shared memory from a daemon process to be communicated, writing a message header into a named pipeline with the daemon process, and writing a message body into the shared memory; and monitoring the named pipeline through the daemon process, and reading the message body from the shared memory. According to the method and the device, interaction of inter-process communication messages can be processed more efficiently.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to an inter-process communication method, device, equipment and medium. Background Art

[0002] In computer systems, communication between processes is a very important and common operation. Common inter-process communication methods such as pipes, sockets, and shared memory can achieve communication and data exchange, but when the amount of communication data is large, these methods are inefficient and will affect system performance. Especially for systems that require fast response or big data processing, an efficient inter-process communication mechanism is particularly important.

[0003] Therefore, a method for more efficiently handling message interactions between processes is currently needed. Summary of the invention

[0004] In order to solve the above technical problems, the present disclosure provides an inter-process communication method, device, equipment and medium.

[0005] According to one aspect of the present disclosure, there is provided an inter-process communication method, comprising:

[0006] Determining the length type of the communication message to be transmitted through the client process; wherein the communication message includes a message header and a message body;

[0007] In the case where the length type of the communication message is a first type of message whose length is not less than a preset length value, applying for a shared memory from the daemon process to be communicated, and writing the message header into a named pipe between the daemon process and the daemon process, and writing the message body into the shared memory;

[0008] The message header in the named pipe is monitored by the daemon process, and the message body is read from the shared memory.

[0009] According to another aspect of the present disclosure, there is also provided an inter-process communication device, comprising:

[0010] A length type determination module, used to determine the length type of a communication message to be transmitted through a client process; wherein the communication message includes a message header and a message body;

[0011] A first transmission module is used to apply for shared memory from the daemon process to be communicated, and write the message header into a named pipe between the daemon process and the daemon process, and write the message body into the shared memory when the length type of the communication message is a first type of message whose length is not less than a preset length value;

[0012] The first message reading module is used to monitor the message header in the named pipe through the daemon process and read the message body from the shared memory.

[0013] According to another aspect of the present disclosure, an electronic device is provided, the electronic device comprising:

[0014] processor;

[0015] a memory for storing instructions executable by the processor;

[0016] The processor is used to read the executable instructions from the memory and execute the instructions to implement the above method.

[0017] According to another aspect of the present disclosure, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and the computer program is used to execute the above method.

[0018] Compared with the prior art, the technical solution provided by the embodiments of the present disclosure has the following advantages:

[0019] The technical solution provided by the embodiment of the present disclosure includes: determining the length type of the communication message to be transmitted through the client process; when the length type of the communication message is a first-class message whose length is not less than a preset length value, applying for shared memory from the daemon process, and writing the message header into a named pipe and the message body into the shared memory; monitoring the message header in the named pipe through the daemon process and reading the message body from the shared memory.

[0020] For the first type of messages with more serious length limitation problems, this technical solution uses shared memory for transmission, making full use of the high bandwidth advantage of shared memory; by using shared memory, the performance overhead caused by the transmission of large amounts of data in named pipes can be avoided. By having the daemon process monitor the named pipe, the daemon process and the ordinary process readers and writers can access the shared memory at the same time without locking or using semaphores, thereby ensuring the orderliness of inter-process communication and the security of data. Therefore, this solution can handle the interaction of inter-process communication messages more efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0022] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0023] Figure 1 This is a flow chart of the inter-process communication method described in an embodiment of the present disclosure;

[0024] Figure 2 A schematic diagram of the first type of message and the second type of message in the embodiment of the present disclosure;

[0025] Figure 3 A schematic diagram of a message queue according to an embodiment of the present disclosure;

[0026] Figure 4 This is a flow chart of another inter-process communication method described in an embodiment of the present disclosure;

[0027] Figure 5 A schematic diagram of the division of functional modules of the process described in the embodiment of the present disclosure;

[0028] Figure 6 It is a structural block diagram of the inter-process communication device described in the embodiment of the present disclosure;

[0029] Figure 7 It is a schematic diagram of the structure of the electronic device described in the embodiment of the present disclosure. DETAILED DESCRIPTION

[0030] In order to more clearly understand the above-mentioned objectives, features and advantages of the present disclosure, the scheme of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0031] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0032] In order to more efficiently process message interactions between processes, the embodiments of the present disclosure provide an inter-process communication method, apparatus, device and medium. The technical solution introduces a daemon process, and based on a "dual-channel" communication mechanism such as named pipes and shared memory, the daemon process classifies and processes first-class messages and second-class messages of different length types, making it more flexible when processing communication messages of different lengths, and effectively responding to various different business needs. For ease of understanding, the embodiments of the present disclosure are described below.

[0033] Figure 1A flowchart of an inter-process communication method provided for an embodiment of the present disclosure, the method can be applicable to large-scale software systems or distributed systems, as well as different scenarios in different fields such as assisted driving, cloud technology and artificial intelligence. The inter-process communication method can be executed by an inter-process communication device, which can be implemented in software and / or hardware, such as an electronic device or a server. Among them, the electronic device may include a vehicle processor, a mobile phone, a tablet computer, a desktop computer, a laptop computer and other devices with communication functions. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. It should be noted that the following embodiments are explained exemplarily with electronic devices as the execution subject.

[0034] like Figure 1 As shown, the inter-process communication method provided by this embodiment may include the following steps.

[0035] S102, determining the length type of the communication message to be transmitted through the client process.

[0036] Electronic devices usually provide business services for various business applications. When providing business services, processes are not isolated, and messages may need to be passed between different processes to implement corresponding business services. In this case, communication between processes is required. When two processes communicate, the two processes can transmit messages to each other. In this embodiment, the client process, as one of the processes that communicate with each other, can be a common process deployed on the electronic device.

[0037] In this embodiment, another process that communicates with the client process is a daemon process. The daemon process plays an important role in program design. It is a special program running in the background.

[0038] The client process and the daemon process may be deployed on the same electronic device or on different electronic devices. When the client process and the daemon process are deployed on different electronic devices, cross-device communication may be achieved.

[0039] In this embodiment, before the client process and other processes to be communicated transmit messages to each other, some preparation work can be done first, such as: when the client process is started, a named pipe is created in a preset first directory according to the PID (Process Identifier) ​​of the client process, and a shared memory is created in a preset second directory.

[0040] In a specific example, after the client process is started, a named pipe named after the PID of the client process can be created in the preset first directory, and the first directory is generally not restricted. Pipes are a half-duplex communication method, and named pipes are a powerful inter-process communication mechanism that supports cross-process and cross-computer communication by providing an accessible path name.

[0041] And, create a shared memory named after the PID of the client process in a preset second directory; the second directory is, for example, the / dev / shm directory; / dev / shm is a very useful directory under Linux, because this directory is not on the hard disk, but in the memory, so under Linux, there is no need to go to great lengths to build a memory disk, and directly using / dev / shm / can achieve a good optimization effect. Shared memory is an efficient inter-process communication method, where data is directly stored in the memory and shared by all processes that need to communicate, and communication is performed by reading and writing the memory segment, and all processes can directly access the shared memory, thereby avoiding data duplication and improving the efficiency of data exchange.

[0042] In this embodiment, the communication messages can be divided into first-class messages and second-class messages according to the length type, wherein the length of the first-class messages is greater than the length of the second-class messages. Based on this, the length type of the communication message to be transmitted is determined by the client process as the first-class message or the second-class message, and its implementation process can refer to the following content.

[0043] The communication message to be transmitted is obtained through the client process; the communication message includes a message header and a message body. Specifically, when it is determined that the client process and the daemon process need to communicate, the client process can obtain the communication message to be transmitted. The message format of the communication message can be referred to Figure 2 and Figure 3 , which includes: a message header and a message body, the message header may include PID, ProcName (program name), msg len type (message length type), timestamp (timestamp) and msg type (message type), and the message body may include msg.

[0044] Determine whether the length of the communication message is less than the preset length value. In a specific example, when the client process needs to transmit a communication message, it can first obtain the length of the communication message according to the message length type field in the message header to determine whether the length of the communication message is less than the preset length value. If yes, the length type bit in the message header is set to the second type message; if no, the length type bit in the message header is set to the first type message.

[0045] Next, the long first-category message and the short second-category message are described respectively. The writing and reading process of the first-category message is described with reference to the following steps S104 and S106.

[0046] S104, when the length type of the communication message is a first type of message whose length is not less than a preset length value, apply for shared memory from the daemon process to be communicated, write the message header into the named pipe between the daemon process and the message body into the shared memory.

[0047] In this embodiment, if the length of the communication message is not less than the preset length value, the length type of the communication message is determined to be a first-class message. For the first-class message, the client process can first apply to the daemon process for shared memory in the shared memory pool. The message body is written into the shared memory, and the shared memory is used to store the message body of the first-class message; and the message header is written into the named pipe between the daemon process and the message header is sent through the named pipe; the message header contains the corresponding message body length.

[0048] In the above embodiments, the communication messages are dynamically processed according to the length type of the communication messages, i.e., the first type messages or the second type messages. For the longer first type messages, the shared memory method is used to improve the processing efficiency of the communication messages.

[0049] By applying for shared memory from the daemon process through the client process, the daemon process and the client process can read and write the shared memory at the same time without locking or using semaphores, ensuring the orderliness of inter-process communication and the security of data.

[0050] S106, monitoring the message header in the named pipe through the daemon process, and reading the message body from the shared memory.

[0051] The implementation process of this embodiment may include: monitoring multiple named pipes under a preset first directory through a daemon process; when a message arrives in the named pipe, reading the message header from the named pipe; wherein the message header includes the length type of the communication message; if it is determined that the length type of the communication message is a first-class message, reading the message body from the shared memory.

[0052] The daemon process monitors all the named pipes in the first directory. When a new message arrives, the message header is read from the named pipe, and the length type of the communication message is determined to be a first-class message or a second-class message according to the message header.

[0053] If it is a first-class message, an idle target thread is allocated to the daemon process from the thread pool, and the message body is read from the shared memory by the target thread. In a specific example, an idle target thread can be provided to process the message for a message body that takes a long time, and the message body is read from the shared memory by the target thread.

[0054] In this embodiment, the daemon process allocates an idle target thread from the thread pool to specifically process the first type of message, which can avoid blocking the main thread's listening, and multiple processes can process messages in parallel, greatly improving the processing efficiency, so that it has better performance in certain specific application scenarios, such as large data volumes and high concurrency scenarios.

[0055] For the first type of message, this embodiment first requests the allocation of shared memory from the daemon process, then writes the message body of the first type of message into the shared memory, and sends the message header containing information such as the message length and the location of the shared memory to the daemon process through a named pipe, and the daemon process reads the message body from the shared memory. Based on the shared memory, the daemon process can process multi-process information by periodically reading the shared memory; based on Figure 3 The message queue shown numbers different messages and reads each communication message in order.

[0056] The transmission method for the first type of message in this embodiment can access the shared memory without locks or semaphores. The client process and the daemon process read and write the shared memory at the same time, ensuring the integrity and consistency of the data, ensuring communication efficiency, and avoiding data confusion. Compared with the traditional daemon process design method, this daemon process design method based on shared memory is more capable of handling high concurrency, large data volume, and high I / O intensive business scenarios.

[0057] In this embodiment, the writing and reading process of the second type of message is described with reference to the following steps S202 and S204.

[0058] S202: When the length type of the communication message is a second type of message whose length is less than a preset length value, the message header and the message body are combined and written into a named pipe.

[0059] In this embodiment, if the length of the communication message is less than the preset length value, the length type of the communication message is determined to be a second-class message. For the second-class message, it can be directly transmitted through a named pipe, that is, the client process combines the message header and the message body into a whole message, and writes the whole message into a named pipe between the client process and the daemon process.

[0060] S204, monitoring the message header in the named pipe through the daemon process, and reading the message body from the named pipe.

[0061] The implementation process of this embodiment may include: monitoring multiple named pipes under a preset first directory through a daemon process; when a message arrives in the named pipe, reading a message header from the named pipe; wherein the message header includes the length type of the communication message; if it is determined according to the message header that the length type of the communication message is a second type of message, continuing to read the message body from the named pipe, and then processing the message body.

[0062] According to the above embodiment, another inter-process communication method can be provided, such as Figure 4 As shown, including the following:

[0063] S301, determining, through a client process, that the length type of a communication message to be transmitted is a first-type message or a second-type message; wherein the length of the first-type message is greater than the length of the second-type message.

[0064] S302, if the communication message is a first-class message, apply for shared memory from the daemon process to be communicated, write the message header into the named pipe between the daemon process and the message body into the shared memory.

[0065] S303: If the communication message is a second-category message, the message header and the message body included in the communication message are merged and written into the named pipe.

[0066] S304, monitoring multiple named pipes in a preset first directory through a daemon process.

[0067] S305, when a message arrives at the named pipe, a message header is read from the named pipe; wherein the message header includes the length type of the communication message.

[0068] S306: If the length type of the communication message is a first-class message, read the message body from the shared memory.

[0069] S307: If the length type of the communication message is a second-class message, the message body is read from the named pipe.

[0070] In the above embodiment, compared with a single pipe or a single shared memory, the above embodiment uses a "dual channel" communication mechanism of a named pipe in conjunction with a shared memory, and adopts a method in which one daemon corresponds to one named pipe and one shared memory. On this basis, the first type of message and the second type of message are distinguished by setting the message length, so that it is more flexible when processing communication messages of different lengths, and the named pipe and the shared memory are used for transmission respectively. The low latency of the named pipe and the high bandwidth of the shared memory are cleverly combined, which can effectively improve the performance problems caused by excessive one-time data reading and writing, so that it has better performance in specific application scenarios such as large data volume and high concurrency, and effectively responds to various different business needs. When the daemon monitors the named pipe, the notification mechanism of the named pipe can ensure that the daemon process and the client process read and write both sides access the shared memory at the same time without locking or using semaphores.

[0071] Therefore, this embodiment can more efficiently process message interactions between processes and greatly improve the operating efficiency of the system by quickly processing a large number of first-category messages and second-category messages from other client processes through the daemon process.

[0072] Reference Figure 5 , this embodiment provides a way to divide different functional modules in a client process and a daemon process. On the client process side, it can include a pipeline management module, a shared memory management module, and a message management module; on the daemon process side, it can include a monitoring module, a pipeline processing module, a shared memory pool module, a shared memory processing module, a message processing module, a thread pool module, and a message storage module. On this basis, the inter-process communication method provided in this embodiment can be specifically referred to as follows.

[0073] When the client process is started, a named pipe is created in the preset first directory according to the PID of the client process through the pipe management module in the client process. The purpose of creating a named pipe is to enable the client process and the daemon process to communicate through the named pipe.

[0074] Through the co-line memory management module in the client process, a shared memory is created in a preset second directory (specifically, the / dev / shm folder).

[0075] A communication message to be transmitted is obtained through a message management module in a client process; the communication message includes a message header and a message body; it is determined whether the length of the communication message is less than a preset length value; if it is less than the preset length value, the length type bit in the message header is set to a second-category message; and after determining that the communication message is a second-category message, the message header and message body included in the communication message are merged and written into a named pipe between the daemon process.

[0076] If it is not less than the preset length value, the length type bit in the message header is set to the first category message; and after determining that the communication message is a first category message, apply for shared memory from the daemon process, write the message header into the named pipe, and write the message body into the shared memory.

[0077] Then, on the daemon process side, a plurality of named pipes in the preset first directory are monitored by a monitoring module in the daemon process, and the monitoring module is used to monitor the event set of the named pipes. When a message arrives at the named pipe, the pipe processing module reads the message header from the named pipe to determine whether the communication message is a first-class message or a second-class message; wherein the message header includes the length type of the communication message.

[0078] If the length type of the communication message is a second-class message, the pipeline processing module continues to read the message body from the named pipeline. If it is determined that the length type of the communication message is a first-class message, the thread pool module first allocates an idle target thread from the thread pool to the daemon process, and then the shared memory processing module reads the message body from the shared memory through the target thread.

[0079] This embodiment also includes: after the daemon process reads the message body, determining a callback function that matches the message type of the communication message; and storing the message body in a preset storage medium through the callback function.

[0080] In a specific embodiment, the message processing module can obtain the message type of the communication message based on the msg type field in the message header, use different callback functions for different message types, encode and decode the message body through the callback function that matches the message type of the communication message, and store the processed message body in a preset storage medium through the message storage module.

[0081] After storing the message body in a preset storage medium through the callback function, the method provided in this embodiment further includes: when the length type of the communication message is a first-category message, releasing the shared memory allocated to the daemon process to the shared memory pool.

[0082] In this embodiment, for the first type of message, after storing the message body of the first type of message in a preset storage medium, the daemon process can release the shared memory back to the shared memory pool through the message storage module, thereby ensuring communication efficiency and avoiding data confusion. The message storage module is responsible for providing the client process with the application and recovery of shared memory to prevent a large amount of memory fragmentation during the interaction process.

[0083] At this point, the transmission process of a communication message between the client process and the daemon process is completed. Figure 3It can be seen that there are multiple communication messages between two processes, so the next communication message can be waited for later, and the next communication message can be processed by referring to the same inter-process communication method mentioned above.

[0084] according to Figure 5 The functional modules of the client process and the daemon process are shown. At the same time, the client process and the daemon process have a clear structure and flexible processing methods. The daemon process can add sockets to the monitoring event set, which also has great advantages in terms of system maintainability and scalability.

[0085] In summary, the inter-process communication method provided by the embodiment of the present disclosure includes: determining the length type of the communication message to be transmitted through the client process; when the length type of the communication message is a first-class message whose length is not less than a preset length value, applying for shared memory from the daemon process to be communicated, and writing the message header into a named pipe between the daemon process and the daemon process, and writing the message body into the shared memory; and reading the message body from the shared memory by monitoring the named pipe through the daemon process.

[0086] In the face of the first type of messages with more serious length limitations, this technical solution uses shared memory for transmission, making full use of the high bandwidth advantage of shared memory; at the same time, the named pipe not only has low latency, but also allows the daemon process and the ordinary process readers and writers to access the shared memory at the same time without locking or using semaphores by monitoring the named pipe through the daemon process, thereby ensuring the orderliness of inter-process communication and the security of data. By using shared memory, the performance overhead caused by the transmission of large amounts of data in the named pipe can be avoided, effectively overcoming the length limitation problem of the first type of messages. In addition, the daemon process can effectively receive and process communication messages from multiple client processes without having to worry about the problem caused by the message length exceeding the maximum length of the named pipe.

[0087] Furthermore, when a large number of common processes (i.e., client processes) randomly send communication messages of different lengths, the technical solution first classifies the communication messages into longer first-class messages or shorter second-class messages through the client process, making it more flexible to process communication messages of different lengths later. For the first-class messages or the second-class messages, named pipes and shared memory are used for transmission respectively, which can not only reduce the number of system calls, but also make full use of the respective advantages of named pipes and shared memory.

[0088] Therefore, this technical solution not only ensures the timeliness of communication message delivery, but also reduces the number of system calls by separating the first-type messages and the second-type messages of different length types, and effectively improves the problem of message queue limiting the message length. In addition, the ability of the daemon process to process information is improved through the call of the thread pool, reducing the risk of the daemon process being blocked.

[0089] Figure 6 This is a structural block diagram of an inter-process communication device provided in an embodiment of the present disclosure. The device can be used to implement the above-mentioned inter-process communication method. The device can be implemented by software and / or hardware, such as an electronic device or a server. Figure 6 As shown, the inter-process communication device may include the following modules.

[0090] The length type determination module 610 is used to determine the length type of the communication message to be transmitted through the client process;

[0091] A first transmission module 620 is used to apply for shared memory from the daemon process to be communicated, and write the message header into a named pipe between the daemon process and the daemon process, and write the message body into the shared memory when the length type of the communication message is a first type of message whose length is not less than a preset length value;

[0092] The first message reading module 630 is used to monitor the message header in the named pipe through the daemon process and read the message body from the shared memory.

[0093] In one embodiment, the first message reading module 630 is further configured to:

[0094] Monitoring the plurality of named pipes in a preset first directory by the daemon process;

[0095] When a message arrives from the named pipe, the message header is read from the named pipe; wherein the message header includes the length type of the communication message;

[0096] If the length type of the communication message is the first type of message, the message body is read from the shared memory.

[0097] In one embodiment, the first message reading module 630 is further configured to:

[0098] An idle target thread is allocated to the daemon process from a thread pool, and the message body is read from the shared memory through the target thread.

[0099] In one embodiment, the device further comprises:

[0100] A creation module is used to create the named pipe in a preset first directory and create a shared memory in a preset second directory according to the process identifier PID of the client process after the client process is started.

[0101] In one embodiment, the device further comprises:

[0102] A storage module, configured to determine a callback function matching a message type of the communication message after the daemon process reads the message body;

[0103] The message body is stored in a preset storage medium through the callback function.

[0104] In one embodiment, after storing the message body in a preset storage medium through the callback function, the device further includes:

[0105] The memory release module is used to release the shared memory allocated to the daemon process to the shared memory pool when the length type of the communication message is a first-class message.

[0106] In one embodiment, the device further comprises:

[0107] A second transmission module, configured to merge the message header and the message body and write the merged message into the named pipe when the length type of the communication message is a second type message whose length is less than the preset length value;

[0108] The second message reading module is used to monitor the message header in the named pipe through the daemon process and read the message body from the named pipe.

[0109] In one embodiment, the length type determination module is further used to:

[0110] Obtaining communication messages to be transmitted through the client process;

[0111] Determining whether the length of the communication message is less than a preset length value;

[0112] If yes, then setting the length type bit in the message header to the second type of message;

[0113] If not, the length type bit in the message header is set to the first type of message.

[0114] The implementation principle and technical effects of the device provided in this embodiment are the same as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0115] Figure 7 The structure diagram of an electronic device provided by the embodiment of the present disclosure is shown in FIG. Figure 7 As shown, the electronic device 700 includes one or more processors 701 and a memory 702 .

[0116] The processor 701 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 700 to perform desired functions.

[0117] The memory 702 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may include, for example, a read-only memory (ROM), a hard disk, a flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 701 may run the program instructions to implement the inter-process communication method of the embodiment of the present disclosure described above and / or other desired functions. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0118] In one example, the electronic device 700 may further include: an input device 703 and an output device 704, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0119] In addition, the input device 703 may also include, for example, a keyboard, a mouse, and the like.

[0120] The output device 704 can output various information to the outside, including the determined distance information, direction information, etc. The output device 704 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0121] Of course, to simplify, Figure 7 Only some of the components related to the present disclosure in the electronic device 700 are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device 700 may also include any other appropriate components.

[0122] Furthermore, this embodiment also provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to execute the above-mentioned inter-process communication method.

[0123] The embodiments of the present disclosure provide a computer program product of an inter-process communication method, apparatus, electronic device, and medium, including a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the previous method embodiments. The specific implementation can be found in the method embodiments, which will not be repeated here.

[0124] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0125] The above description is only a specific embodiment of the present disclosure, so that those skilled in the art can understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An inter-process communication method, characterized in that: include: Determining the length type of the communication message to be transmitted through the client process; wherein the communication message includes a message header and a message body; In the case where the length type of the communication message is a first type of message whose length is not less than a preset length value, applying for a shared memory from the daemon process to be communicated, and writing the message header into a named pipe between the daemon process and the daemon process, and writing the message body into the shared memory; The message header in the named pipe is monitored by the daemon process, and the message body is read from the shared memory.

2. The method according to claim 1, characterized in that The step of monitoring the message header in the named pipe through the daemon process and reading the message body from the shared memory includes: Monitoring the plurality of named pipes in a preset first directory by the daemon process; When a message arrives from the named pipe, the message header is read from the named pipe; wherein the message header includes the length type of the communication message; If the length type of the communication message is the first type of message, the message body is read from the shared memory.

3. The method according to claim 2, characterized in that The reading the message body from the shared memory comprises: An idle target thread is allocated to the daemon process from a thread pool, and the message body is read from the shared memory through the target thread.

4. The method according to claim 1, characterized in that The method further comprises: When the client process is started, the named pipe is created in a preset first directory according to the process identifier PID of the client process, and the shared memory is created in a preset second directory.

5. The method according to claim 1, characterized in that The method further comprises: After the daemon process reads the message body, determining a callback function that matches the message type of the communication message; The message body is stored in a preset storage medium through the callback function.

6. The method according to claim 5, characterized in that After storing the message body in a preset storage medium through the callback function, the method further includes: In a case where the length type of the communication message is a first-category message, the shared memory allocated to the daemon process is released to a shared memory pool.

7. The method according to claim 1, characterized in that The method further comprises: In the case where the length type of the communication message is a second type of message whose length is less than the preset length value, the message header and the message body are merged and then written into the named pipe; The message header in the named pipe is monitored by the daemon process, and the message body is read from the named pipe.

8. The method according to claim 7, characterized in that The determining, by the client process, the length type of the communication message to be transmitted includes: Obtaining communication messages to be transmitted through the client process; Determining whether the length of the communication message is less than a preset length value; If yes, then setting the length type bit in the message header to the second type of message; If not, the length type bit in the message header is set to the first type of message.

9. An inter-process communication device, characterized in that: include: A length type determination module, used to determine the length type of a communication message to be transmitted through a client process; wherein the communication message includes a message header and a message body; A first transmission module is used to apply for shared memory from the daemon process to be communicated, and write the message header into a named pipe between the daemon process and the daemon process, and write the message body into the shared memory when the length type of the communication message is a first type of message whose length is not less than a preset length value; The first message reading module is used to monitor the message header in the named pipe through the daemon process and read the message body from the shared memory.

10. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the instructions to implement the method described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a terminal device, the terminal device implements the method according to any one of claims 1 to 8.

Images