Inter-process communication method and apparatus, related devices, products and storage medium

Abstract

The method comprises the following steps: writing the to-be-transmitted message data carried in a message sending request into an idle slot of a shared message slot pool and generating a target message descriptor request; converting the target message descriptor request into a message readable completion event; writing the message readable completion event into a completion event information queue; reading the to-be-transmitted message data from the shared message slot pool according to the slot identifier in the message readable completion event; and carrying data by using the shared message slot pool and processing events by using a shared ring queue, so that the number of system calls and data copying times during inter-process communication is significantly reduced, the switching overhead between the kernel mode and the user mode is reduced, meanwhile, the standard read-write, polling and other interfaces are completely compatible, the efficiency and stability of cross-process data interaction are greatly improved, and the unification of high performance and ease of use is realized.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of communication technology, specifically to an inter-process communication method, apparatus, related equipment, product, and storage medium. Background Technology

[0002] In the Linux operating system, inter-process communication (IPC) is a fundamental capability supporting multi-process collaboration, local service interaction, and program execution. Traditional IPC mechanisms mainly include anonymous pipes, named pipes, shared memory, and message queues. Among these, pipes are widely used for data exchange between parent and child processes, local services, and script runtime due to their simple interface and strong compatibility.

[0003] With the increasing prevalence of high-frequency, short-message, and high-concurrency local communication scenarios, the performance bottlenecks of existing IPC mechanisms are becoming increasingly apparent. Traditional pipes rely on independent read / write system calls for each send and receive operation, requiring frequent switching between user and kernel modes. The smaller the message granularity, the greater the system overhead. Furthermore, the reliance on kernel wait queues and task wake-ups results in high backpressure and scheduling costs, making them unsuitable for high-concurrency scenarios. While shared memory can reduce data copying overhead, it requires the application layer to maintain message boundaries, free slots, synchronization and mutual exclusion, and resource reclamation, making implementation complex, exception handling difficult, and incompatible with existing pipe interfaces, leading to high migration and modification costs.

[0004] Therefore, it is necessary to propose an inter-process communication method to solve at least one of the above-mentioned technical problems. Summary of the Invention

[0005] Embodiments of this disclosure provide an inter-process communication method, apparatus, related devices, products, and storage medium.

[0006] Firstly, this disclosure provides an inter-process communication method that runs in the operating system kernel mode, including: In response to a message sending request from the sending process, the message data to be transmitted carried in the message sending request is written into an empty slot in the shared message slot pool; Based on the slot identifier of the free slot for writing the message data to be transmitted and the attribute information of the message data to be transmitted, a target message descriptor request is generated. The target message descriptor request is used to indicate that the message data to be transmitted has been written and to request notification to the receiving process. Submit the target message descriptor request to the submission queue in the shared circular queue; The target message descriptor request in the submission queue is processed to generate a corresponding message readable completion event, and the message readable completion event is written into the completion event information queue in the shared circular queue. In response to the receiving process obtaining the message readable completion event from the completion event information queue, the message data to be transmitted is read from the shared message slot pool according to the slot identifier carried in the message readable completion event.

[0007] In some optional implementations, the step of writing the message data to be transmitted carried in the message sending request into an idle slot of the shared message slot pool in response to the message sending request of the sending process includes: Determine the target free slot among the free slots in the shared message slot pool; Write the message data to be transmitted into the target free slot; In response to the completion of writing the message data to be transmitted, the target free slot is marked as an occupied slot, and the slot identifier of the target free slot is recorded as the target free slot identifier associated with the message data to be transmitted.

[0008] In some optional implementations, submitting the target message descriptor request to the submission queue in the shared circular queue includes: The target message descriptor request is written into the submission queue item of the submission queue. The opcode field of the submission queue item is set to a preset no opcode. The preset no opcode is used to instruct the kernel not to perform input / output operations on the target message descriptor request, and to directly write the message readable completion event corresponding to the target message descriptor request into the completion event information queue.

[0009] In some optional implementations, the method further includes: In response to the receiving process reading the message data to be transmitted, a reclaim descriptor request is submitted to the submission queue, the reclaim descriptor request carrying the target free slot identifier; Based on the target free slot identifier in the reclaim descriptor request, the target free slot is remarked from the occupied state to the free state.

[0010] In some optional implementations, the method further includes: In response to the sending process calling a standard write operation, a target free slot is determined in the free slots of the shared message slot pool, the message data to be transmitted is written into the target free slot, and a target message descriptor request is submitted to the submission queue. In response to the receiving process calling a standard read operation, the message readable completion event is obtained from the completion event information queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

[0011] In some optional implementations, the method further includes: In response to the sending process or the receiving process calling the standard polling operation, the writable condition is determined based on the number of free slots in the shared message slot pool, and the readable condition is determined based on the number of unread message readable completion events in the completion event information queue. When the writable condition is met, the standard write operation is performed. When the readable conditions meet the preset readable conditions, the standard read operation is performed.

[0012] In some optional implementations, the method further includes: In response to the associated instruction that invokes the named communication endpoint, an index node is created for the named communication endpoint, and an identifier bit is set in the index node to indicate that the named communication endpoint uses the shared circular queue for communication; Based on the identifier bit, the index node is associated with the shared circular queue and the shared message slot pool.

[0013] In some optional implementations, the method further includes: In response to a standard write operation on a named communication endpoint, the associated shared message slot pool and the shared circular queue are obtained based on the index node. The message data to be transmitted is written into an empty slot in the shared message slot pool, and the target message descriptor request is submitted to the submission queue of the shared circular queue. In response to a standard read operation on the named communication endpoint, the associated shared circular queue is obtained according to the index node, the message readable completion event is obtained from the completion event information queue of the shared circular queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

[0014] Secondly, this disclosure provides an inter-process communication device that runs in the operating system kernel mode, including: The message data to be transmitted writing unit is configured to write the message data to be transmitted carried in the message sending request to the free slot of the shared message slot pool in response to the message sending request of the sending process. The generation unit is configured to generate a target message descriptor request based on the slot identifier of the free slot in which the message data to be transmitted is written and the attribute information of the message data to be transmitted. The target message descriptor request is used to indicate that the message data to be transmitted has been written and to request notification to the receiving process. The request submission unit is configured to submit the target message descriptor request to the submission queue in the shared circular queue; The message readable completion event writing unit is configured to process the target message descriptor request in the submission queue, generate a corresponding message readable completion event, and write the message readable completion event into the completion event information queue in the shared circular queue. The reading unit is configured to, in response to the receiving process obtaining the message readable completion event from the completion event information queue, read the message data to be transmitted from the shared message slot pool according to the slot identifier carried in the message readable completion event.

[0015] In some optional implementations, the message data writing unit to be transmitted is configured as follows: Determine the target free slot among the free slots in the shared message slot pool; Write the message data to be transmitted into the target free slot; In response to the completion of writing the message data to be transmitted, the target free slot is marked as an occupied slot, and the slot identifier of the target free slot is recorded as the target free slot identifier associated with the message data to be transmitted.

[0016] In some optional implementations, the request submission unit is configured as follows: The target message descriptor request is written into the submission queue item of the submission queue. The opcode field of the submission queue item is set to a preset no opcode. The preset no opcode is used to instruct the kernel not to perform input / output operations on the target message descriptor request, and to directly write the message readable completion event corresponding to the target message descriptor request into the completion event information queue.

[0017] In some alternative embodiments, the apparatus further includes: In response to the receiving process reading the message data to be transmitted, a reclaim descriptor request is submitted to the submission queue, the reclaim descriptor request carrying the target free slot identifier; Based on the target free slot identifier in the reclaim descriptor request, the target free slot is remarked from the occupied state to the free state.

[0018] In some alternative embodiments, the apparatus further includes: In response to the sending process calling a standard write operation, a target free slot is determined in the free slots of the shared message slot pool, the message data to be transmitted is written into the target free slot, and a target message descriptor request is submitted to the submission queue. In response to the receiving process calling a standard read operation, the message readable completion event is obtained from the completion event information queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

[0019] In some alternative embodiments, the apparatus further includes: In response to the sending process or the receiving process calling the standard polling operation, the writable condition is determined based on the number of free slots in the shared message slot pool, and the readable condition is determined based on the number of unread message readable completion events in the completion event information queue. When the writable condition is met, the standard write operation is performed. When the readable conditions meet the preset readable conditions, the standard read operation is performed.

[0020] In some alternative embodiments, the apparatus further includes: In response to the associated instruction that invokes the named communication endpoint, an index node is created for the named communication endpoint, and an identifier bit is set in the index node to indicate that the named communication endpoint uses the shared circular queue for communication; Based on the identifier bit, the index node is associated with the shared circular queue and the shared message slot pool.

[0021] In some alternative embodiments, the apparatus further includes: In response to a standard write operation on a named communication endpoint, the associated shared message slot pool and the shared circular queue are obtained based on the index node. The message data to be transmitted is written into an empty slot in the shared message slot pool, and the target message descriptor request is submitted to the submission queue of the shared circular queue. In response to a standard read operation on the named communication endpoint, the associated shared circular queue is obtained according to the index node, the message readable completion event is obtained from the completion event information queue of the shared circular queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

[0022] Thirdly, this disclosure provides an electronic device, including: One or more processors; Storage device, on which one or more programs are stored, When the above-described one or more programs are executed by the above-described one or more processors, the above-described one or more processors implement the method as described in any embodiment of the first aspect of this disclosure.

[0023] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by one or more processors, implements the method described in any embodiment of the first aspect of this disclosure.

[0024] Fifthly, this disclosure provides a computer program product including a computer program / instructions that, when executed by a processor, implement the method described in any embodiment of the first aspect of this disclosure.

[0025] The inter-process communication method, apparatus, electronic device, and storage medium provided in the embodiments of this disclosure firstly, in response to a message sending request from a sending process, writes the message data to be transmitted carried in the message sending request into an idle slot of a shared message slot pool; then, based on the slot identifier of the idle slot into which the message data to be transmitted is written and the attribute information of the message data to be transmitted, a target message descriptor request is generated; next, the target message descriptor request is submitted to the submission queue in a shared circular queue; then, the target message descriptor request in the submission queue is processed to generate a corresponding message readable completion event, and the message readable completion event is written into the completion event information queue in the shared circular queue; finally, in response to the receiving process obtaining the message readable completion event from the completion event information queue, the message data to be transmitted is read from the shared message slot pool based on the slot identifier carried in the message readable completion event. Thus, by using a shared message slot pool to carry data and a shared circular queue to process events, the number of system calls and data copies during inter-process communication is significantly reduced, the switching overhead between kernel mode and user mode is reduced, and standard read / write and polling interfaces are fully compatible, greatly improving the efficiency and stability of cross-process data interaction and achieving a balance between high performance and ease of use. Attached Figure Description

[0026] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings: Figure 1 This is an exemplary system architecture diagram to which one embodiment of this disclosure can be applied; Figure 2A This is a flowchart of an embodiment of the inter-process communication method disclosed herein; Figure 2B This is an exploded flowchart of one embodiment of step 2001 according to the present disclosure; Figure 2C This is a schematic diagram of the architecture provided in one embodiment of the present invention; Figure 2DThis is a schematic diagram of message slot state transition provided in one embodiment of the present invention; Figure 2E This is a schematic diagram of inter-process communication timing interaction provided in one embodiment of the present invention; Figure 2F This is a schematic diagram of a named endpoint communication process provided in one embodiment of the present invention; Figure 3 This is a schematic diagram of a structure of an embodiment of an inter-process communication device according to the present disclosure; Figure 4 This is a schematic diagram of the structure of a computer system suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0027] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0028] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the inter-process communication methods, apparatuses, electronic devices, and storage media of this disclosure can be applied.

[0030] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0031] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as inter-process communication applications, voice interaction applications, video conferencing applications, short video social applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0032] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with microphones and speakers, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), portable computers, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules, or as a single software program or software module. No specific limitations are made here.

[0033] Server 105 can be a server that provides various services, such as a background server on terminal devices 101, 102, and 103 that writes the message data to be transmitted carried in the message sending request into an empty slot in the shared message slot pool. The background server can process the message data to be transmitted accordingly.

[0034] In some cases, the inter-process communication method provided in this disclosure can be jointly executed by terminal devices 101, 102, and 103 and server 105. For example, the step of "writing the message data to be transmitted carried in the message transmission request to an empty slot in the shared message slot pool in response to the message transmission request of the sending process" can be executed by terminal devices 101, 102, and 103, and the step of "generating a target message descriptor request based on the slot identifier of the empty slot where the message data to be transmitted is written and the attribute information of the message data to be transmitted" can be executed by server 105. This disclosure does not limit this. Accordingly, inter-process communication devices can also be respectively set in terminal devices 101, 102, and 103 and server 105.

[0035] In some cases, the inter-process communication method provided in this disclosure can be executed by server 105, and correspondingly, the inter-process communication device can also be set in server 105. In this case, system architecture 100 may not include terminal devices 101, 102, and 103.

[0036] In some cases, the inter-process communication method provided in this disclosure can be executed by terminal devices 101, 102, and 103. Correspondingly, the inter-process communication device can also be set in terminal devices 101, 102, and 103. In this case, the system architecture 100 may not include server 105.

[0037] It should be noted that server 105 can be either hardware or software. When server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules (for example, used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0038] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0039] Continue to refer to Figure 2A , Figure 2A A flow 2000 is shown as an embodiment of an inter-process communication method according to the present disclosure, which runs in operating system kernel mode.

[0040] Figure 2A The inter-process communication method shown can be applied to Figure 1 The terminal device or server shown. This process 2000 includes the following steps: Step 2001: In response to the message sending request of the sending process, write the message data to be transmitted carried in the message sending request into the free slot of the shared message slot pool.

[0041] In this embodiment, the execution entity of the inter-process communication method (e.g.) Figure 1 The server (105) can first respond to the message sending request of the sending process by writing the message data to be transmitted into an empty slot in the shared message slot pool. Here, the sending process refers to the process instance in the operating system that needs to send data to the receiving process. The sending process can be a child process in a parent-child process relationship, a local service process, or any user-mode thread or task that uses this method for inter-process communication.

[0042] A message sending request is an event or call initiated by the sending process to trigger a data transmission operation. This request can be generated by a user-space program actively calling the communication interface to inform the kernel that data needs to be transmitted. A message sending request must at least include the address of the user-space buffer containing the data to be transmitted, the data length, and the identifier of the target receiver.

[0043] The message data to be transmitted refers to any form of information content that the sending process wishes to pass to the receiving process. The message data to be transmitted can be structured messages (e.g., protocol headers, serialized objects), unstructured byte streams (e.g., log text, binary data blocks), file descriptors (transmitted via auxiliary data), or any combination of the above. The length of the message data to be transmitted can be the capacity range of one or more message slots.

[0044] A shared message slot pool is a shared memory region pre-allocated by the kernel and mapped to the address spaces of the communicating processes. It is divided into several fixed-length or variable-length message slots. Each message slot carries a complete message body and its header metadata, including at least the slot number, message length, message type, and sequence number. The shared message slot pool decouples the data plane from the control plane. The message body is no longer copied byte-by-byte through the kernel buffer of a traditional pipe; instead, it is written directly to the shared slot. The receiver reads directly from the same shared slot, avoiding multiple data transfers between kernel and user space. An idle slot is a message slot in the shared message slot pool that is not currently occupied.

[0045] In some alternative implementations, step 2001 may include, for example: Figure 2B The following steps 20011 to 20013 are shown: Step 20011: Determine the target free slot in the free slots of the shared message slot pool.

[0046] Here, the target free slot refers to the specific message slot allocated by the message sending operation to carry the message data to be transmitted. Each slot has a unique slot identifier in the shared message slot pool, which is used to index the starting address and length information of the slot in the shared message slot pool.

[0047] As an example, free slot management is implemented through a free slot manager. The free slot manager maintains a bitmap that corresponds one-to-one with the total number of slots, where 0 in the bitmap represents free and 1 represents occupied. In response to a message sending request from a sending process, the free slot manager traverses the bitmap, searching for a bit with a current value of 0. If at least one free slot is found, the free slot is marked as 1, and the position index corresponding to the free slot is read. This index is the slot identifier of the target free slot. If there are no free slots, the behavior is determined based on the file flag of the communication endpoint. For example, in blocking mode, the sending process is added to the write wait queue of the communication endpoint until it is awakened after the receiving process releases the slot; in non-blocking mode, an EAGAIN error is immediately returned to the sending process.

[0048] By determining the target free slot from the free slots in the shared message slot pool, multiple sending processes can concurrently apply for free slots without conflicting with each other. This ensures the efficiency and correctness of message slot allocation in high-concurrency multi-producer scenarios, thereby improving the overall throughput performance of inter-process communication.

[0049] Step 20012: Write the message data to be transmitted into the target free slot.

[0050] By writing the message data to be transmitted into the target free slot, the message body carrying path and the control notification path are separated, so that the transmission of each message data no longer requires an independent system call to enter the kernel.

[0051] Step 20013: In response to the completion of writing the message data to be transmitted, the target free slot is marked as an occupied slot, and the slot identifier of the target free slot is recorded as the target free slot identifier associated with the message data to be transmitted.

[0052] Here, an occupied slot refers to a message slot that has been allocated by the sending process, is currently being used, or is about to be used to carry message data to be transmitted, but has not yet been consumed and reclaimed by the receiving process. An occupied slot is used to exclusively reserve the right to use the slot during the transmission of the message data, preventing multiple sending ends from simultaneously writing data to the same slot, which could lead to message overwriting or corruption.

[0053] As an example, the free slot manager in the kernel updates the bitmap, changing the slot corresponding to the target free slot from an idle state to an occupied state. After marking, subsequent sending processes will not obtain the slot identifier when requesting a free slot, until the slot is reclaimed by the receiving process and remarked as free.

[0054] The target free slot identifier is an index that uniquely identifies a message slot. It can be an integer starting from 0, an offset in a bitmap, or an offset address based on a shared memory base address. The target free slot identifier includes the position index of the target free slot in the shared message slot pool, the starting address of the shared memory corresponding to the target free slot, and the fixed length of the target free slot. When the sending end constructs a target message descriptor request, the target free slot identifier is written into the request to inform the kernel which slot the current submission corresponds to. When the kernel generates a message readable completion event, the target free slot identifier is carried to the completion event information queue. When the receiving end reads the completion event information, it quickly locates the corresponding slot in the shared message slot pool based on the target free slot identifier, thereby reading the message body of the message data to be transmitted. When the receiving end performs a reclamation confirmation operation, it marks the corresponding slot as free based on the target free slot identifier.

[0055] By marking the target free slot as occupied in response to the completion of writing the message data to be transmitted, and recording the slot identifier of the target free slot as the target free slot identifier associated with the message data to be transmitted, the sending end achieves exclusive ownership and precise indexing of the newly created message in the shared message slot pool. This avoids slot reuse and data overwriting problems that may occur when multiple processes write concurrently, ensuring the integrity and orderliness of message transmission. At the same time, it provides a reliable status basis for the receiving end to quickly and accurately locate and read the complete message based on the slot identifier carried in the completion event, thereby improving the reliability and efficiency of inter-process shared memory communication.

[0056] Step 2002: Generate a target message descriptor request based on the slot identifier of the free slot for writing the message data to be transmitted and the attribute information of the message data to be transmitted.

[0057] Here, a target message descriptor request refers to a submission queue entry submitted to the submission queue in the shared circular queue. It indicates that the message data to be transmitted has been written and requests notification to the receiving process. It includes the target free slot identifier corresponding to the message data to be transmitted, the length of the message data to be transmitted, the message sequence number, and the target receiver identifier. The opcode for the target message descriptor request is set to IORING_OP_NOP, which indicates that no actual input / output operation is required; the kernel can directly convert the target message descriptor request into the corresponding completion event after consuming it.

[0058] As an example, the target message descriptor request is generated as follows: After receiving the commit instruction from the sending process, the kernel allocates an idle commit queue item from the commit queue, and fills the corresponding fields of the commit queue according to parameters such as the target idle slot identifier, message length, monotonically increasing sequence number allocated by the sequence number watermark manager, and receiver identifier, to form a complete message descriptor request.

[0059] The attribute information of the message data to be transmitted refers to the control metadata written in the target message descriptor request, which describes the characteristics of the message transmission, such as message type, priority, acknowledgment mode identifier, or sender context identifier. This information is used to enable the receiver to make message distribution decisions or resource scheduling in advance based on the attribute information when it obtains the message readable completion event from the completion event information queue, without having to immediately read the complete data body in the shared message slot pool, thereby improving communication efficiency and processing flexibility.

[0060] By generating a target message descriptor request based on the slot identifier of the free slot for writing the message data to be transmitted and the attribute information of the message data to be transmitted, the message notification path and the actual data transport are decoupled, thereby avoiding the additional system calls and kernel path overhead caused by performing actual input / output operations in traditional inter-process communication.

[0061] Step 2003: Submit the target message descriptor request to the submission queue in the shared circular queue.

[0062] Here, the shared circular queue refers to the asynchronous processing queue structure provided by the operating system kernel, which consists of a commit queue and a completion event information queue. It is used to carry message descriptor submission, completion event notification and status transfer in an asynchronous manner between processes, so as to realize efficient inter-process communication with separation of control plane and data plane.

[0063] As an example, a target message descriptor request can be written to a commit queue entry in the commit queue. The opcode field of the commit queue entry is set to a preset no-opcode. The preset no-opcode is used to instruct the kernel not to perform input / output operations on the target message descriptor request, but to directly write the message read-complete event corresponding to the target message descriptor request to the completion event information queue.

[0064] By submitting target message descriptor requests to the submission queue in the shared circular queue, batch submission of multiple target message descriptor requests is achieved, thereby reducing the number of interactions between user space and kernel space and reducing the system call overhead in high-frequency small message scenarios.

[0065] Step 2004: Process the target message descriptor request in the submission queue, generate the corresponding message readable completion event, and write the message readable completion event into the completion event information queue in the shared circular queue.

[0066] Here, a readable message completion event refers to a completion queue entry written to the completion event information queue in the shared circular queue. It includes the target free slot identifier, message length, and message sequence number. The readable message completion event is used to notify the receiving process that a ready-to-read readable message exists in the shared message slot pool. The receiving process can obtain the target free slot identifier of the message by reading this readable message completion event and read the message body from the shared message slot pool.

[0067] As an example, when converting a target message descriptor request into a message readable completion event, if the kernel recognizes that the opcode of the target message descriptor request is set to a special type that does not require actual input / output operations, since the opcode indicates that no actual hardware I / O or file system operations are required, the kernel skips the regular data transfer path and directly allocates an empty completion queue entry in the completion event information queue based on the parameters such as the target free slot identifier, message length, and message sequence number filled in the target message descriptor request. The kernel then writes the above parameters into the corresponding fields of the completion queue entry, thereby forming a complete message readable completion event.

[0068] By converting the target message descriptor request into a message readable completion event, the message body data is decoupled, thus avoiding the path overhead of the receiving end needing to actively call the read system call to copy data from the kernel buffer in traditional inter-process communication. This allows the receiving end to know that a new message has arrived simply by reading the completion event information queue.

[0069] Step 2005: In response to the receiving process obtaining a message readable completion event from the completion event information queue, the message data to be transmitted is read from the shared message slot pool according to the slot identifier carried in the message readable completion event.

[0070] Here, the completion event information queue is used to store completion event information.

[0071] As an example, after converting the target message descriptor request into a message-readable completion event, the executing entity writes the message-readable completion event into a completion event information queue for the receiving process to read. The completion event information queue is a shared circular queue paired with the submission queue, used to store completion event information corresponding to completed requests. Each completion event corresponds to a target message descriptor request that has been consumed.

[0072] The kernel obtains the tail pointer of the completion event queue, writes the readable completion event to the queue entry pointed to by the tail pointer, and then updates the tail pointer to make the readable completion event visible to the user-space receiving process. If the completion event queue is full, the kernel will block or return an error based on the backpressure mechanism.

[0073] In another embodiment, the receiving process invokes a standard read operation or directly accesses the completion event information queue via user-mode polling. Upon receiving a message readable completion event, it extracts the slot identifier from the event. The kernel calculates the starting address of the target free slot in the shared memory region based on the slot identifier. Combining this with the message length in the completion event information, it copies the stored message data to be transmitted from the shared memory region to the user-mode buffer specified by the receiving process. If the message length is less than or equal to the single-slot capacity, the entire message is copied in one operation. If the message is stored in segments, it is reassembled and copied based on the first, middle, and last segment flags and a unified sequence number.

[0074] By notifying the receiving process that a message is ready to read via a completion event information queue, and by directly carrying the slot identifier, the receiving process can accurately locate the target data in the shared message slot pool without actively polling whether the message is ready or traversing to find the slot where the message is located. This achieves efficient one-to-one wake-up and zero-copy data reading, which reduces CPU idle overhead and the number of data copies, significantly improving the real-time performance and throughput of inter-process communication.

[0075] In some optional implementations, the aforementioned executing entity may also execute steps 2006 and 2007 after completing step 2005: Step 2006: In response to the receiving process reading the message data to be transmitted, a reclaim descriptor request is submitted to the submission queue. The reclaim descriptor request carries the target slot identifier.

[0076] Here, the recycling descriptor request is a management descriptor submitted by the receiving process to the submission queue. The operation type is slot recycling, and it carries the target slot identifier. After the receiving process completes data reading, it is used to explicitly notify the sending end that the shared message slot has been released and can be resubmitted and reused, thereby realizing the orderly flow and lock-free recycling of slots throughout their entire life cycle.

[0077] By having the receiving process actively submit a request to reclaim the descriptor, the right to use the slot is returned. This means that the allocation and release of slots are driven by the descriptor, eliminating the need for additional lock synchronization or centralized management overhead.

[0078] Step 2007: Based on the target slot identifier in the recycling descriptor request, re-mark the target slot from the occupied state to the idle state.

[0079] As an example, a background task is set up in the sending process to handle recycling requests. This background task continuously retrieves recycling descriptor requests from the submission queue, parses the target slot identifier carried by the recycling descriptor request, and then locates the corresponding slot control block in the shared message slot pool. It changes the status flag in the slot control block from a value representing "occupied" to a value representing "idle", so that the slot can be reallocated and used by subsequent new message sending operations.

[0080] By remarking the target slot from an occupied state to an idle state, the message slot resources are released explicitly and in a timely manner. This allows a limited number of message slots to be efficiently reused in multiple message transmission cycles, avoiding sender blocking and throughput performance degradation caused by long-term slot occupation.

[0081] In some optional implementations, the aforementioned executing entity may also execute steps 2008 and 2009 after completing step 2007: Step 2008: In response to the sending process calling the standard write operation, determine the target free slot in the free slots of the shared message slot pool, write the message data to be transmitted into the target free slot, and submit the target message descriptor request to the submission queue.

[0082] Here, to maintain compatibility with existing inter-process communication interfaces, the executing entity supports the sending process calling standard write operations to complete message sending. A standard write operation refers to a write operation that conforms to the portable operating system interface specification or is semantically consistent with existing pipe interfaces. Standard write operations are used to send data from the user-mode buffer to the communication peer.

[0083] Specifically, the standard write operation is mapped through the compatibility layer file interface to first determine the target free slot in the free slots of the shared message slot pool and write the message data to be transmitted into the target free slot, and then submit the target message descriptor request to the submission queue.

[0084] By mapping standard write operations to data writing to a shared message slot pool and target message descriptor request submission to a commit queue, the kernel can process multiple target message descriptor requests in a batch submission manner, thereby reducing the number of calls for a single message data to be transmitted while maintaining interface compatibility.

[0085] Step 2009: In response to the receiving process calling the standard read operation, retrieve the message readable completion event from the completion event information queue, and read the message data to be transmitted from the shared message slot pool according to the slot identifier in the message readable completion event.

[0086] Here, a standard read operation refers to a read operation that conforms to the system interface specification or is consistent with the semantics of the existing pipe interface. A standard read operation is used to receive data from the communication peer and copy it into the user-space buffer.

[0087] Specifically, the standard read operation is mapped through the compatibility layer file interface to first obtain a message readable completion event from the completion event information queue, then locate and read the message data to be transmitted from the shared message slot pool according to the slot identifier in the message readable completion event, and finally copy the message data to be transmitted to the user-space buffer specified by the receiving process.

[0088] By mapping the receiving process's standard read operation to retrieving a message-readable completion event from the completion event information queue and reading the message data to be transmitted from the shared message slot pool based on the slot identifier in the message-readable completion event, efficient message reading is achieved by reusing the shared message slot pool and the completion event information queue while maintaining standard interface compatibility. This reduces data copying and system call overhead, and improves the throughput performance and response speed of inter-process communication.

[0089] In some optional implementations, the aforementioned executing entity may also execute steps 20010 to 20012 after completing step 2009: Step 20010: In response to the sending process or receiving process calling the standard polling operation, determine the writable condition based on the number of free slots in the shared message slot pool, and determine the readable condition based on the number of unread message readable completion events in the completion event information queue.

[0090] Here, the standard polling operation refers to the standard interface operation called by the sending or receiving process to query the readable and writable status of the current communication endpoint in order to realize event-driven inter-process communication.

[0091] The writable condition refers to the existence of a sufficient number of free slots in the shared message slot pool for allocation, used to determine whether the sending process can immediately execute message sending without being blocked. The readable condition refers to the existence of unread message readable completion events in the completion event information queue, used to determine whether the receiving process can immediately read valid message data without being blocked.

[0092] By defining writable and readable conditions, full compatibility with the semantics of the standard polling interface is achieved, thus adapting to inter-process communication methods without modifying business logic. At the same time, the event state is uniformly maintained by the kernel, reducing the synchronization complexity of the application layer.

[0093] Step 20011: When the writable conditions are met, execute the standard write operation.

[0094] Here, the preset writable condition refers to the existence of available free slots in the shared message slot pool. This is used to determine whether the sending process has the resource conditions to immediately perform a standard write operation, avoiding blocking due to a lack of free slots. The preset writable condition is determined in real time by the kernel based on a bitmap maintained by the free slot manager.

[0095] By executing standard write operations only when preset writable conditions are met, precise flow control and backpressure management of the sending end are achieved, thereby avoiding invalid system calls and improving the execution efficiency and communication stability of standard write operations.

[0096] Step 20012: When the readable conditions meet the preset readable conditions, perform a standard read operation.

[0097] Here, the preset readable condition refers to the existence of unread message readable completion events in the completion event information queue. This is used to determine whether the receiving process can immediately read valid message data from the shared message slot pool, avoiding empty polling and blocking waits when there are no messages. The preset readable condition is determined in real time by the kernel based on the number of readable events in the completion event information queue.

[0098] By performing standard read operations only when preset readable conditions are met, an efficient event-driven reading mode is achieved at the receiving end, thereby reducing invalid waiting, lowering process scheduling overhead, and improving the real-time performance and overall throughput of message reception.

[0099] In some optional implementations, the aforementioned executing entity may also execute steps 20013 to 20014 after completing step 20012: Step 20013: In response to the invocation of the associated instruction for the named communication endpoint, an index node is created for the named communication endpoint, and the flag bits are set in the index node.

[0100] Here, the flag is used to indicate that the named communication endpoints communicate using a shared circular queue.

[0101] Association instructions are primitives used to bind a named communication endpoint to an established shared circular queue. After the association instruction is invoked, the system creates a corresponding index node for the named communication endpoint and writes specific flag bits into the index node. This indicates that subsequent message sending and receiving operations of the named communication endpoint will no longer go through the traditional socket buffer, but will be performed directly based on the shared circular queue, thereby achieving seamless connection between the communication endpoint and the application layer shared memory mechanism.

[0102] Named communication endpoints are pathname-addressable inter-process communication channels with first-in-first-out (FIFO) semantics. They support the establishment of local communication connections between unrelated processes, enabling cross-process data exchange and collaboration. An inode is the core metadata structure of the virtual file system used to manage file objects, carrying information such as permissions, reference counts, lifecycle, and private communication context for named communication endpoints.

[0103] By creating index nodes and setting flag bits for named communication endpoints, the efficient communication mode of shared circular queues can be enabled while preserving the original naming pipe usage habits and system compatibility. This reduces the latency and system overhead of cross-process data interaction and improves communication performance and stability in high-concurrency scenarios.

[0104] Step 20014: Associate the index node with the shared circular queue and the shared message slot pool based on the identifier bit.

[0105] Here, after recognizing the identifier bit in the inode, the kernel points the private data of the inode to the created shared circular queue, and binds the memory address and slot management structure of the shared message slot pool to the inode, so that all read, write and polling operations initiated through this named communication endpoint can use the same set of shared circular queue and shared message slot pool to complete data interaction.

[0106] As an example, step 20014 may include steps A and B: Step A: In response to the standard write operation on the named communication endpoint, obtain the associated shared message slot pool and shared circular queue based on the index node, write the message data to be transmitted into the free slot in the shared message slot pool, and submit the target message descriptor request to the commit queue of the shared circular queue.

[0107] Here, when the application initiates a standard write operation on the aforementioned named communication endpoint, it locates the corresponding shared message slot pool and commit queue based on the shared circular queue association information recorded in the index node for the named communication endpoint. It then searches for an idle slot in the shared message slot pool, copies the message data to be sent to the data area of ​​that slot, and finally writes the target message descriptor request containing the slot identifier and message length into the commit queue of the shared circular queue to complete the data transmission.

[0108] Step B: In response to a standard read operation on a named communication endpoint, obtain the associated shared circular queue based on the index node, retrieve the message readable completion event from the completion event information queue of the shared circular queue, and read the message data to be transmitted from the shared message slot pool based on the slot identifier in the message readable completion event.

[0109] Here, when an application initiates a standard read operation on the same named communication endpoint, it obtains the corresponding shared circular queue based on the index node, polls its completion event information queue, and once it obtains a message read completion event containing a slot identifier, it directly reads the message data from the corresponding slot in the shared message slot pool based on the slot identifier and returns it to the application layer.

[0110] By associating index nodes with shared circular queues and shared message slots based on identifier bits, the application layer can directly utilize the shared circular queue for efficient data exchange through standard file operation interfaces without needing to be aware of the differences in the underlying communication mechanisms, thus avoiding the overhead of multiple memory copies and context switching in traditional protocol stacks.

[0111] Continue to refer to Figure 2C This is a schematic diagram of the architecture provided in one embodiment of the present invention. Figure 2C As shown, this architecture includes a sending process (TaskA), a receiving process (TaskB), a shared message slot pool, an idle slot manager, a polling thread (i.e., the SQPOLL thread), and an io_uring control plane. The shared message slot pool carries the message body; the idle slot manager manages slot allocation and reclamation; and the io_uring control plane internally contains a commit queue (SQ) and a completion queue (CQ). The specific interaction relationships are as follows: The sending process TaskA requests a free slot from the free slot manager. After obtaining the slot, it writes the message body to the shared message slot pool. At the same time, TaskA submits the message descriptor SQE to the io_uring control plane.

[0112] The polling thread performs SQPOLL consumption, and the io_uring control plane generates a readable CQE accordingly, and is responsible for releasing credits and slots back to the free slot manager.

[0113] The receiving process TaskB reads the CQE from the io_uring control plane, retrieves messages according to the slot number in the CQE, and submits a retrieval confirmation to the io_uring control plane after completion, thus completing a complete message delivery.

[0114] Continue to refer to Figure 2D This is a schematic diagram of message slot state transition provided in one embodiment of the present invention. Figure 2D As shown, a message slot undergoes the following state transitions throughout its complete lifecycle: First, the message slot is in an idle state. After the sender requests an idle slot, the message slot enters a reserved state. Once in the reserved state, the sender writes the message body and slot header, and the message slot becomes filled. Then, the control plane generates a readable completion queue element, and the message slot becomes visible. Next, after the receiver completes reading, the message slot enters a consumed state. Finally, a retrieval confirmation is performed, and credits are released. The message slot eventually returns to an idle state, completing one cycle, thus ensuring the safe reuse of slots and the orderly visibility of messages.

[0115] Continue to refer to Figure 2E This is a schematic diagram of inter-process communication timing interaction provided in an embodiment of the present invention. Figure 2E As shown, the timing of this method in a complete communication is as follows: The TaskA sender interacts with the kernel io_uring context. The TaskA sender initializes the communication context and maps the message slot pool. The kernel io_uring context returns the context, credit, and slot information.

[0116] TaskA sends an application for an empty slot and writes the data into the body of the application. Then, TaskA sends an application containing the slot number, length, and sequence number (SQE).

[0117] The SQPOLL thread verifies the slot status and consumes the SQE. Then, the kernel io_uring context writes a readable CQE into the CQ. The TaskB receiver reads the CQE and locates the message slot. Subsequently, the TaskB receiver reads the message body according to the message boundaries and submits a retrieval confirmation to the kernel io_uring context. Finally, the kernel io_uring context releases the slot and replenishes the credit.

[0118] Continue to refer to Figure 2F This is a schematic diagram of a named communication endpoint process provided in one embodiment of the present invention. Figure 2F As shown, the processing flow for naming communication endpoints is as follows: 1. When a user creates a named communication endpoint, the kernel creates a FIFO semantic inode for that named communication endpoint.

[0119] 2. Determine if the named communication endpoint carries the io_uring private identifier. If so, bind uring_pipe_fops to the shared context, and subsequent open / read / write / poll operations will use message slots and the CQ protocol. If not, maintain normal FIFO file operations and process along the original FIFO path.

[0120] The inter-process communication method provided in the above embodiments of this disclosure first responds to the message sending request of the sending process by writing the message data to be transmitted carried in the message sending request into an idle slot of a shared message slot pool. Then, a target message descriptor request is generated based on the slot identifier of the idle slot into which the message data to be transmitted is written and the attribute information of the message data to be transmitted. Next, the target message descriptor request is submitted to the submission queue in the shared circular queue. Then, the target message descriptor request in the submission queue is processed to generate a corresponding message readable completion event, and the message readable completion event is written into the completion event information queue in the shared circular queue. Finally, in response to the receiving process obtaining the message readable completion event from the completion event information queue, the message data to be transmitted is read from the shared message slot pool based on the slot identifier carried in the message readable completion event. In this way, by using a shared message slot pool to carry data and a shared circular queue to process events, the number of system calls and data copies during inter-process communication is significantly reduced, the switching overhead between kernel mode and user mode is reduced, and standard read / write and polling interfaces are fully compatible. This greatly improves the efficiency and stability of cross-process data interaction and achieves a balance between high performance and ease of use.

[0121] Further reference Figure 3 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of an inter-process communication device, which is similar to... Figure 2A Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0122] like Figure 3As shown, the inter-process communication device 300 of this embodiment runs in the operating system kernel mode and includes: a message data writing unit 301 to be transmitted, a generation unit 302, a request submission unit 303, a message readability completion event writing unit 304, and a reading unit 305. The system includes a message data writing unit 301, configured to write the message data to be transmitted carried in the message sending request to an idle slot in a shared message slot pool in response to a message sending request from a sending process; a generation unit 302, configured to generate a target message descriptor request based on the slot identifier of the idle slot where the message data to be transmitted is written and the attribute information of the message data to be transmitted, wherein the target message descriptor request is used to indicate that the message data to be transmitted has been written and to request notification to the receiving process; a request submission unit 303, configured to submit the target message descriptor request to a submission queue in a shared circular queue; a message readable completion event writing unit 304, configured to process the target message descriptor request in the submission queue, generate a corresponding message readable completion event, and write the message readable completion event to a completion event information queue in the shared circular queue; and a reading unit 305, configured to read the message data to be transmitted from the shared message slot pool based on the slot identifier carried in the message readable completion event when the receiving process retrieves the message readable completion event from the completion event information queue.

[0123] In this embodiment, the specific processing of the message data writing unit 301, generation unit 302, request submission unit 303, message readable completion event writing unit 304, and reading unit 305 of the inter-process communication device 300, and the resulting technical effects, can be referred to respectively. Figure 2A The relevant descriptions of steps 2001, 2002, 2003, 2004, and 2005 in the corresponding embodiments will not be repeated here.

[0124] In some optional implementations, the message data writing unit 301 to be transmitted may be further configured as follows: Determine the target free slot among the free slots in the shared message slot pool; Write the message data to be transmitted into the target free slot; In response to the completion of writing the message data to be transmitted, the target free slot is marked as an occupied slot, and the slot identifier of the target free slot is recorded as the target free slot identifier associated with the message data to be transmitted.

[0125] In some alternative implementations, the request submission unit 303 may be further configured as follows: The target message descriptor request is written into the submission queue item of the submission queue. The opcode field of the submission queue item is set to a preset no opcode. The preset no opcode is used to instruct the kernel not to perform input / output operations on the target message descriptor request, and to directly write the message readable completion event corresponding to the target message descriptor request into the completion event information queue.

[0126] In some optional embodiments, the inter-process communication device 300 further includes: In response to the receiving process reading the message data to be transmitted, a reclaim descriptor request is submitted to the submission queue, the reclaim descriptor request carrying the target free slot identifier; Based on the target free slot identifier in the reclaim descriptor request, the target free slot is remarked from the occupied state to the free state.

[0127] In some optional embodiments, the inter-process communication device 300 further includes: In response to the sending process calling a standard write operation, a target free slot is determined in the free slots of the shared message slot pool, the message data to be transmitted is written into the target free slot, and a target message descriptor request is submitted to the submission queue. In response to the receiving process calling a standard read operation, the message readable completion event is obtained from the completion event information queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

[0128] In some optional embodiments, the inter-process communication device 300 further includes: In response to the sending process or the receiving process calling the standard polling operation, the writable condition is determined based on the number of free slots in the shared message slot pool, and the readable condition is determined based on the number of unread message readable completion events in the completion event information queue. When the writable condition is met, the standard write operation is performed. When the readable conditions meet the preset readable conditions, the standard read operation is performed.

[0129] In some optional embodiments, the inter-process communication device 300 further includes: In response to the associated instruction that invokes the named communication endpoint, an index node is created for the named communication endpoint, and an identifier bit is set in the index node to indicate that the named communication endpoint uses the shared circular queue for communication; Based on the identifier bit, the index node is associated with the shared circular queue and the shared message slot pool.

[0130] In some optional embodiments, the inter-process communication device 300 further includes: In response to a standard write operation on a named communication endpoint, the associated shared message slot pool and the shared circular queue are obtained based on the index node. The message data to be transmitted is written into an empty slot in the shared message slot pool, and the target message descriptor request is submitted to the submission queue of the shared circular queue. In response to a standard read operation on the named communication endpoint, the associated shared circular queue is obtained according to the index node, the message readable completion event is obtained from the completion event information queue of the shared circular queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

[0131] It should be noted that the implementation details and technical effects of each module and unit in the inter-process communication device 300 provided in the embodiments of this disclosure can be referred to the descriptions of other embodiments in this disclosure, and will not be repeated here.

[0132] The inter-process communication device provided in this disclosure, through the coordinated operation of a message data writing unit, a generation unit, a request submission unit, a message readable completion event writing unit, and a reading unit in kernel mode, allows the message data writing unit to write the message data to be transmitted from the sending process into an idle slot of a shared message slot pool. The generation unit generates a target message descriptor request accordingly, the request submission unit submits the request to the submission queue of a shared circular queue, the message readable completion event writing unit processes the request and generates a corresponding message readable completion event completion event information queue, and the reading unit responds to the receiving process's read operation, directly reading data from the shared message slot pool based on the slot identifier in the completion event. Thus, by using a shared message slot pool to carry data and a shared circular queue to process events, the number of system calls and data copies during inter-process communication is significantly reduced, the switching overhead between kernel mode and user mode is lowered, and standard read / write and polling interfaces are fully compatible, greatly improving the efficiency and stability of cross-process data interaction and achieving a balance between high performance and ease of use.

[0133] The following is for reference. Figure 4 It shows a schematic diagram of the structure of a computer system 400 suitable for implementing the terminal device of this disclosure. Figure 4 The computer system 400 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0134] like Figure 4As shown, the computer system 400 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the computer system 400. The processing device 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0135] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows computer system 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 A computer system 400 with various electronic devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0136] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined in the methods of embodiments of this disclosure.

[0137] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0138] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0139] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the following functions: Figure 2A The embodiments shown and their alternative implementations illustrate inter-process communication methods.

[0140] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0142] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The names of the units are not necessarily limiting in certain circumstances; for example, a unit for writing message data to be transmitted can also be described as "a unit that writes message data to be transmitted into an empty slot of a shared message slot pool in response to a message sending request from a sending process."

[0143] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. An inter-process communication method, characterized in that, Running in the operating system kernel mode, the method includes: In response to a message sending request from the sending process, the message data to be transmitted carried in the message sending request is written into an empty slot in the shared message slot pool; Based on the slot identifier of the free slot for writing the message data to be transmitted and the attribute information of the message data to be transmitted, a target message descriptor request is generated. The target message descriptor request is used to indicate that the message data to be transmitted has been written and to request notification to the receiving process. Submit the target message descriptor request to the submission queue in the shared circular queue; The target message descriptor request in the submission queue is processed to generate a corresponding message readable completion event, and the message readable completion event is written into the completion event information queue in the shared circular queue. In response to the receiving process obtaining the message readable completion event from the completion event information queue, the message data to be transmitted is read from the shared message slot pool according to the slot identifier carried in the message readable completion event.

2. The method according to claim 1, characterized in that, The step of responding to a message sending request from the sending process by writing the message data to be transmitted carried in the message sending request into an empty slot in the shared message slot pool includes: Determine the target free slot among the free slots in the shared message slot pool; Write the message data to be transmitted into the target free slot; In response to the completion of writing the message data to be transmitted, the target free slot is marked as an occupied slot, and the slot identifier of the target free slot is recorded as the target free slot identifier associated with the message data to be transmitted.

3. The method according to claim 1, characterized in that, The step of submitting the target message descriptor request to the submission queue in the shared circular queue includes: The target message descriptor request is written into the submission queue item of the submission queue. The opcode field of the submission queue item is set to a preset no opcode. The preset no opcode is used to instruct the kernel not to perform input / output operations on the target message descriptor request, and to directly write the message readable completion event corresponding to the target message descriptor request into the completion event information queue.

4. The method according to claim 1, characterized in that, The method further includes: In response to the receiving process reading the message data to be transmitted, a reclaim descriptor request is submitted to the submission queue, the reclaim descriptor request carrying a target free slot identifier; Based on the target free slot identifier in the reclaim descriptor request, the target free slot is remarked from the occupied state to the free state.

5. The method according to claim 1, characterized in that, The method further includes: In response to the sending process calling a standard write operation, a target free slot is determined in the free slots of the shared message slot pool, the message data to be transmitted is written into the target free slot, and a target message descriptor request is submitted to the submission queue. In response to the receiving process calling a standard read operation, the message readable completion event is obtained from the completion event information queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

6. The method according to claim 1, characterized in that, The method further includes: In response to the sending process or the receiving process calling the standard polling operation, the writable condition is determined based on the number of free slots in the shared message slot pool, and the readable condition is determined based on the number of unread message readable completion events in the completion event information queue. When the writable conditions are met, a standard write operation is performed. When the readable conditions meet the preset readable conditions, a standard read operation is performed.

7. The method according to claim 1, characterized in that, The method further includes: In response to the associated instruction that invokes the named communication endpoint, an index node is created for the named communication endpoint, and an identifier bit is set in the index node to indicate that the named communication endpoint uses the shared circular queue for communication; Based on the identifier bit, the index node is associated with the shared circular queue and the shared message slot pool.

8. The method according to claim 7, characterized in that, The method further includes: In response to a standard write operation on the named communication endpoint, the associated shared message slot pool and the shared circular queue are obtained according to the index node, the message data to be transmitted is written into an empty slot in the shared message slot pool, and the target message descriptor request is submitted to the submission queue of the shared circular queue. In response to a standard read operation on the named communication endpoint, the associated shared circular queue is obtained according to the index node, the message readable completion event is obtained from the completion event information queue of the shared circular queue, and the message data to be transmitted is read from the shared message slot pool according to the slot identifier in the message readable completion event.

9. An inter-process communication device, running in the kernel mode of an operating system, the device comprising: The message data to be transmitted writing unit is configured to write the message data to be transmitted carried in the message sending request to the free slot of the shared message slot pool in response to the message sending request of the sending process. The generation unit is configured to generate a target message descriptor request based on the slot identifier of the free slot in which the message data to be transmitted is written and the attribute information of the message data to be transmitted. The target message descriptor request is used to indicate that the message data to be transmitted has been written and to request notification to the receiving process. The request submission unit is configured to submit the target message descriptor request to the submission queue in the shared circular queue; The message readable completion event writing unit is configured to process the target message descriptor request in the submission queue, generate a corresponding message readable completion event, and write the message readable completion event into the completion event information queue in the shared circular queue. The reading unit is configured to, in response to the receiving process obtaining the message readable completion event from the completion event information queue, read the message data to be transmitted from the shared message slot pool according to the slot identifier carried in the message readable completion event.

10. An electronic device, comprising: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method as described in any one of claims 1-8.

11. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1-8.

12. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the method as described in any one of claims 1-8.

Images