Inter-process communication method and device based on shared memory, equipment and storage medium

Abstract

The invention relates to an inter-process communication method and device based on a shared memory, equipment and a storage medium, and the method comprises the steps: constructing a bidirectional shared memory channel based on a first shared memory region and a second shared memory region between a host process and a sandbox process; the host process writes the instruction data into the first shared memory area and updates the corresponding instruction state mark; when the sandbox process detects that the instruction state mark is a first target state, reading and executing the instruction data from the first shared memory area, generating result data, writing the result data into a second shared memory area, and updating a corresponding result state mark; when the host process detects that the result state is marked as a second target state, reading and executing the result data from the second shared memory area; compared with the prior art, the technical scheme of the invention can realize low-delay and high-order cross-process communication between the host and the sandbox by constructing the two-way channel of the double shared memory regions.

Description

Technical Field

[0001] This application relates to the technical field of communication, and in particular to an inter-process communication method, apparatus, device and storage medium based on shared memory. Background Technology

[0002] In the field of enterprise security and virtualization management, sandbox systems need to conduct cross-process communication with host services at high frequency to complete key business interactions such as approval status synchronization, file import and export command transmission, and sandbox operation status feedback. Such scenarios have strict requirements on the real-time performance, reliability, and resource utilization efficiency of communication, and the performance of the communication mechanism directly affects the collaborative management effect between the sandbox and the host.

[0003] Currently, cross-process communication between the sandbox and the host mainly relies on three traditional solutions: first, socket-based network communication, which requires establishing and maintaining network connections and ports between the two; second, file polling, which exchanges messages by reading and writing preset local files, requiring the sandbox and the host to periodically scan the files to detect new data; and third, using databases or message queue middleware, relying on third-party components to implement message storage and forwarding.

[0004] However, the above solutions have obvious drawbacks: the socket solution requires opening network ports, which not only increases the complexity of security review and deployment, but also increases transmission latency due to network protocol overhead; the file polling solution has poor real-time performance in instruction-intensive scenarios, and is prone to approval timeouts or state asynchrony; the database / message queue solution requires additional deployment and maintenance middleware, which increases the system construction and operation and maintenance costs, and is difficult to adapt in isolated environments; the existing solutions cannot simultaneously meet the requirements of "low latency, low resource consumption, high reliability, and easy deployment", and there is an urgent need for a cross-process communication mechanism that is more suitable for this scenario. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for inter-process communication based on shared memory. By constructing a bidirectional channel with dual shared memory regions and using status flags to control the interaction between instructions and results, low-latency and highly ordered cross-process communication can be achieved between the host and the sandbox, effectively solving the problems of poor real-time performance, high resource consumption, or complex deployment of traditional communication schemes.

[0006] In a first aspect, this application provides an inter-process communication method based on shared memory for communication between a host process and a sandbox process, comprising: constructing a bidirectional shared memory channel between the host process and the sandbox process based on a first shared memory region and a second shared memory region; the host process writing instruction data into the first shared memory region and updating the instruction status flag of the first shared memory region; when the sandbox process detects that the instruction status flag is a first target state, reading and executing the instruction data from the first shared memory region to generate result data; the sandbox process writing the result data into the second shared memory region and updating the result status flag of the second shared memory region; when the host process detects that the result status flag is a second target state, reading and executing the result data from the second shared memory region.

[0007] In one possible implementation, the construction of a bidirectional shared memory channel between the host process and the sandbox process, based on a first shared memory region and a second shared memory region, specifically includes: when the host process starts, it creates the first shared memory region and the second shared memory region according to a preset name, writes corresponding header field information to the first shared memory region and the second shared memory region, and registers a host-side callback function for processing the result data; after the sandbox process starts, it maps the first shared memory region and the second shared memory region according to the preset name, sets the channel state of the bidirectional shared memory channel to a ready state, and registers a sandbox-side callback function for processing the instruction data; the host process and the sandbox process complete a handshake based on the header field information and the ready state to confirm the establishment of the bidirectional shared memory channel.

[0008] In one possible implementation, the instruction data includes a fixed header and a variable parameter section; wherein the fixed header includes an instruction identifier, an instruction sequence number, an initialization flag, a data length, and a checksum; the variable parameter section includes parameter information corresponding to the instruction type, and the parameter information includes at least one of target path, service identifier, user identifier, session verification information, and timeout threshold.

[0009] In one possible implementation, before the host process writes instruction data into the first shared memory region, the method further includes: determining whether the initialization flag in the fixed header is set; if the initialization flag is set, resetting the data buffer of the first shared memory region, resetting the synchronization mechanism associated with the first shared memory region and the instruction sequence number, and waiting for the state of the sandbox process to become ready before performing the writing of instruction data and the updating of the instruction status flag.

[0010] In one possible implementation, when the sandbox process detects that the instruction status marker is a first target state, it reads and executes the instruction data from the first shared memory region to generate result data. Specifically, this includes: the sandbox process monitoring the instruction status marker and channel sequence number in the first shared memory region; when it detects that the instruction status marker is the pending state and the channel sequence number increments, it updates the instruction status marker to the executing state; it reads and parses the instruction data from the first shared memory region and performs corresponding operations; and it generates result data based on the first execution result of the instruction data, wherein the result data includes at least a result code, message type, and an impact approval list marker.

[0011] In one possible implementation, generating result data based on the first execution result of the instruction data specifically includes: setting the result code in the result data as a success identifier, a failure identifier, or a retry identifier according to the execution status of the first execution result of the instruction data; setting the corresponding message type in the result data according to the instruction type corresponding to the instruction data; determining whether the first execution result causes a change in the core data status of the approval business, and if so, setting the impact approval list marker in the result data.

[0012] In one possible implementation, when the host process detects that the result status marker is a second target status, it reads and executes the result data from the second shared memory region. Specifically, this includes: when the host process detects that the result status marker in the second shared memory region has changed to a completed status, it reads the result data from the second shared memory region; it calls the host-side callback processing function and executes a target processing operation matching the message type in the result data based on the host-side callback processing function; and when the impact approval list marker in the result data is set, it automatically initiates an approval list synchronization operation.

[0013] Secondly, this application provides an inter-process communication device based on shared memory for communication between a host process and a sandbox process, comprising: a bidirectional shared memory channel construction module, an instruction data writing module, an instruction data execution module, a result data writing module, and a result data execution module; wherein, the bidirectional shared memory channel construction module is used to construct a bidirectional shared memory channel between the host process and the sandbox process based on a first shared memory region and a second shared memory region; the instruction data writing module is used to write instruction data into the first shared memory region and update the instruction status flag of the first shared memory region; the instruction data execution module is used to read and execute the instruction data from the first shared memory region to generate result data when the instruction status flag is detected to be a first target state; the result data writing module is used to write the result data into the second shared memory region and update the result status flag of the second shared memory region; the result data execution module is used to read and execute the result data from the second shared memory region when the host process detects that the result status flag is a second target state.

[0014] Thirdly, embodiments of this application also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0015] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0016] This application provides an inter-process communication method, apparatus, device, and storage medium based on shared memory, which has the following advantages compared with the prior art:

[0017] This method establishes a bidirectional shared memory channel between the host process and the sandbox process, based on a first shared memory region and a second shared memory region. The host process writes instruction data into the first shared memory region and updates the instruction status flag in the first shared memory region. When the sandbox process detects that the instruction status flag is a first target state, it reads and executes the instruction data from the first shared memory region to generate result data. The sandbox process then writes the result data into the second shared memory region and updates the result status flag in the second shared memory region. When the host process detects that the result status flag is a second target state, it reads and executes the result data from the second shared memory region. Compared with existing technologies, the technical solution of this application relies on shared memory for direct data reading and writing, without going through a network protocol stack, significantly reducing transmission latency and... This system minimizes system resource consumption and eliminates the need for open network ports, avoiding additional security audit costs and external attack risks. Compared to existing file polling solutions, its precise triggering mechanism—using instruction status markers and first target status, as well as result status markers and second target status—allows the sandbox to instantly detect pending instructions and the host to instantly obtain processing results. This avoids issues such as insufficient real-time performance, approval timeouts, or status asynchronization caused by periodic scanning. Furthermore, compared to solutions relying on databases or message queues, it eliminates the need to deploy and maintain third-party middleware, significantly reducing system construction and maintenance complexity and offering stronger adaptability in environments with high isolation requirements. Additionally, the bidirectional channel design with dual shared memory areas achieves physical separation of instruction issuance and result feedback. Combined with status marker-based control of the interaction process, this effectively avoids data read / write conflicts, ensuring the orderliness and reliability of high-frequency business interactions between the host and the sandbox. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1This is a flowchart illustrating an embodiment of an inter-process communication method based on shared memory provided in this application;

[0022] Figure 2 This is a schematic diagram of an embodiment of an inter-process communication device based on shared memory provided in this application;

[0023] Figure 3 This is a schematic diagram of the structure of a computer device provided in this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0026] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0027] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0028] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0030] Example 1, see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of an inter-process communication method based on shared memory provided in this application, as shown below. Figure 1 As shown, this method is used for communication between the host process and the sandbox process, including steps 101-105, as follows:

[0031] Step 101: Establish a bidirectional shared memory channel between the host process and the sandbox process, based on the first shared memory region and the second shared memory region.

[0032] In one embodiment, when the host process starts, it creates the first shared memory region and the second shared memory region according to a preset name, writes the corresponding header field information to the first shared memory region and the second shared memory region, and registers a host-side callback function for processing the result data.

[0033] Specifically, the host process creates a first memory-mapped file with a first fixed name pre-defined by the system, and creates a second memory-mapped file with a second fixed name pre-defined by the system. The first memory-mapped file corresponds to a first shared memory-mapped file, and the second memory-mapped file corresponds to a second shared memory-mapped file.

[0034] Preferably, a first shared memory region is created with the first fixed name HostToSandbox, and a second shared memory region is created with the second fixed name SandboxToHost.

[0035] Specifically, the first shared memory region serves as the channel for the host process to send instruction data to the sandbox process, while the second shared memory region serves as the channel for the sandbox process to send result data to the host process. This dual-region separation design enables parallel processing of instruction issuance and result return, avoiding read / write conflicts in a single region. Furthermore, based on preset naming, it ensures that after the sandbox process starts, it can accurately locate and map these two shared memory regions without needing to negotiate addresses, thus directly establishing a communication link.

[0036] Specifically, the host process writes header field information to the first shared memory region and the second shared memory region respectively. This establishes a unified interaction rule for communication between the host process and the sandbox process, ensuring the consistency and security of data reading and writing.

[0037] Specifically, the header field information includes at least the following core information: magic number field, version number field, capacity field, and mutex name field. The magic number field serves as an identity identifier, used to verify the legitimacy of the shared memory region after the sandbox process maps, preventing accidental connections to other shared memory regions. The version number field ensures compatibility between different versions of the host process and the sandbox process, preventing data parsing failures due to protocol differences. The capacity field defines the storage limit of each shared memory region, preventing data overflow. The mutex name field provides an identifier for synchronization control of subsequent read and write operations, ensuring that only one party performs write operations on the shared memory region at a time, preventing data overwriting or corruption. Writing these header fields allows the sandbox process to quickly obtain the key configurations required for communication after mapping the shared memory region, enabling data exchange to begin without additional interaction, laying a rule-based foundation for efficient communication.

[0038] Specifically, the host process registers host-side callback functions to handle the result data, replacing the traditional polling mode and enabling real-time processing of the sandbox process's result data. While creating two shared memory regions and writing corresponding header fields, the host process pre-builds a mapping relationship between result types and processing logic, such as a Cmd ID → Handler callback table. The registered host-side callback functions are specifically used to handle the result data returned by the sandbox process. For example, for different types of results such as approval results, file operation completion, and sandbox offline notifications, corresponding processing branches are bound. For instance, the approval result callback function updates the cache and UI; the file operation callback function triggers user prompts; and the abnormal result callback function logs or retryes. The registration of the host-side callback functions is synchronized with the shared memory initialization, ensuring that the first result data returned after the sandbox process starts can be captured immediately, without the host process continuously scanning the shared memory.

[0039] In one embodiment, after the sandbox process starts, it maps the first shared memory region and the second shared memory region according to the preset naming, sets the channel status of the bidirectional shared memory channel to the ready state, and registers a sandbox-side callback processing function for processing the instruction data.

[0040] Specifically, after the sandbox process starts, it maps the first and second shared memory regions with preset names to establish a precise point-to-point communication connection with the host process, which is a prerequisite for bidirectional data interaction. The preset names are exactly the same as the names used by the host process when creating the first and second shared memory regions. Through these fixed preset names, the sandbox process can directly locate the two shared memory regions created by the host process in the operating system without additional address negotiation or connection establishment procedures. The mapping operation essentially associates the two memory-mapped files created by the host process with the address space of the sandbox process, granting the sandbox process read and write permissions to these two shared memory regions. This mapping method based on preset names ensures the uniqueness and stability of the communication link and avoids accidental connections to other shared memory regions.

[0041] Specifically, after the sandbox process completes the shared memory mapping, it sets the channel status of the bidirectional shared memory channel to the READY state and writes the READY state into the header field information of the first shared memory region to synchronize the communication preparation signal to the host process, thus clearing the state obstacles for subsequent instruction interaction.

[0042] Preferably, the channel states of the bidirectional shared memory channel include, but are not limited to, initialization state (INIT), ready state (READY), and recovery state (RECOVER).

[0043] Specifically, the sandbox process switches its state from INIT to READY, meaning it has completed address mapping and permission verification and has the ability to read instructions and write results. At the same time, this state is written to the header field of the first shared memory area. By continuously verifying the state information in the first shared memory area, the host process can accurately determine whether the sandbox process is ready, avoiding data loss or processing failure caused by issuing instructions when the sandbox process is not ready. This state synchronization mechanism is the key to ensuring the orderly collaboration between the host process and the sandbox process.

[0044] Specifically, the sandbox process registers a sandbox-side callback function for processing instruction data, and binds the callback function to the status bits and event signals of the first shared memory region. The core is to establish a trigger-based response logic for instruction arrival and immediate processing, replacing the traditional polling mode and improving the real-time performance of instruction processing.

[0045] Specifically, when the sandbox process registers a sandbox-side callback function for processing instruction data, it registers callback functions for handling different instruction types, including at least an instruction processing callback function and a timeout processing callback function; the callback function is bound to the status bit changes and event signal triggering of the first shared memory region; when the host process writes an instruction to the first shared memory region and sets the status to pending, the corresponding event signal is triggered to immediately wake up and execute the sandbox-side callback function.

[0046] In other words, the sandbox process registers dedicated sandbox-side callback functions such as `onCommand` (instruction processing) and `onTimeout` (timeout handling), and binds them to the status bits and event signals of the first shared memory region. When the host process writes an instruction to the first shared memory region and sets the status to `PENDING`, the corresponding event signal is triggered, directly waking up the sandbox process's `onCommand` callback function, without the sandbox process continuously scanning the memory region. These callback functions predefine the processing logic for different instruction types. For example, when a file export approval instruction is received, the callback function will trigger operations such as permission verification and file retrieval; when a sandbox start instruction is received, the sandbox instance initialization process will be triggered. The registration of callback functions allows the sandbox process to capture instructions in real time and execute them quickly.

[0047] In one embodiment, the host process and the sandbox process complete a handshake based on the header field information and the ready state to confirm the establishment of the bidirectional shared memory channel.

[0048] Specifically, the handshake process between the host process and the sandbox process is essentially a two-way confirmation between the two parties by verifying core information to determine whether the communication carrier is legitimate and whether the other party has the ability to communicate, and finally reaching a consensus that instructions and results can be exchanged securely.

[0049] Specifically, the header field information is the core basis for determining the legitimacy of the carrier, and the ready status is the key signal for determining the capability ready; the two work together to ensure that the physical carrier, communication rules, and the status of both parties in the bidirectional shared memory channel meet the interaction requirements, and avoid communication failure due to carrier mismatch, inconsistent rules, or one party not being ready.

[0050] Specifically, when the host process and the sandbox process complete the handshake based on the header field information and the ready state, the sandbox process maps the first shared memory region and the second shared memory region created by the host process, reads the first header field information of the first shared memory region, and reads the second header field information of the second shared memory region. The sandbox process verifies the first header field information and the second header field information respectively. After the verification of the first header field information and the second header field information is successful, the sandbox process updates the channel state of the shared memory region from the initial state to the ready state and writes the updated state into the header field information corresponding to the first shared memory region. The host process listens to the channel state in the header field information corresponding to the first shared memory region, and when it detects that the channel state has changed to the ready state and the sequence number is valid, it confirms that the sandbox process has completed initialization. When the host process completes the verification of the legality, version compatibility, and capacity adaptation of the header field information, and confirms that the channel state is in the ready state, it determines that the handshake is complete and activates the bidirectional shared memory channel composed of the first shared memory region and the second shared memory region.

[0051] Specifically, when the host process completes the verification of the header field information and detects that the channel status set by the sandbox is READY, the handshake process is officially completed and the bidirectional shared memory channel is activated. At this time, the host process can write instruction data to the first shared memory area and update the status flag at any time, and the sandbox process can also capture instruction data in real time through the sandbox-side callback processing function. Conversely, the result data after the sandbox process completes its execution can also be sent back to the host through the second shared memory area, triggering the host-side callback processing. The entire handshake process does not require additional message interaction, and only completes bidirectional confirmation through the header field information and status flag in the shared memory, which ensures both the security and reliability of communication.

[0052] Preferably, to improve the adaptability of bidirectional communication to multiple service scenarios, the first shared memory region and the second shared memory region can be expanded into a multiplexing architecture to achieve parallel processing of different service instructions.

[0053] Specifically, a Channel Id and QueueOffset / Length are added to the header fields of the first and second shared memory regions, respectively. The Channel Id is used to distinguish different service types, such as approval instructions corresponding to Channel Id=1, file operation instructions corresponding to Channel Id=2, and heartbeat detection instructions corresponding to Channel Id=3. Each Channel Id corresponds to an independent instruction status flag, result status flag, and mutex lock to ensure that read and write operations of different channels do not interfere with each other. The QueueOffset / Length is used to define the starting position and data length of each channel in the shared memory region to avoid data overlap between different channels.

[0054] Specifically, the scheduling logic of the first and second shared memory regions can adopt either event-driven or polling-by-channel approaches. In event-driven mode, when the instruction status flag of a certain shared memory region changes to pending status, the callback function of the corresponding shared memory region is directly triggered. In polling mode, the scheduling thread traverses each channel identifier (Channel Id) in a preset order, detects and processes instructions to be executed. This setting allows high-frequency services such as approval, documents, and heartbeats to interact in parallel in independent queues, avoiding the backlog of single service instructions from affecting overall communication efficiency. It is especially suitable for complex scenarios of multi-service concurrency in enterprise sandboxes.

[0055] Preferably, to meet the differentiated needs of business for instruction processing timeliness, a priority field and a deadline field can be added to the fixed header of the instruction data to achieve priority scheduling of high-priority instructions.

[0056] Specifically: When the host process issues instructions, it sets priority words according to the urgency of the business, such as setting urgent approvals as the highest priority and regular file queries as normal priority, and defines the latest execution time of the instructions through the deadline field; the sandbox process maintains a priority queue, and after receiving instructions, sorts them according to the rule of descending priority field and ascending deadline field, and prioritizes reading and executing high-priority instructions or instructions with close deadlines from the head of the queue; if a high-priority instruction preempts during execution, such as receiving an urgent approval instruction while executing a normal instruction, the sandbox process will pause the current normal instruction, save the execution progress to a temporary area in shared memory, and resume the execution of the normal instruction after the high-priority instruction is completed; at the same time, the host process will write back the execution order change notification through the first shared memory area to inform the host process of the preemption of the high-priority instruction, ensuring that both parties have a consistent understanding of the instruction execution order; this solution can avoid delays in critical business, such as security alarm response and urgent approval, caused by blocking of low-priority instructions, and improve the system's responsiveness to urgent business.

[0057] Step 102: The host process writes instruction data into the first shared memory region and updates the instruction status flag of the first shared memory region.

[0058] In one embodiment, the instruction data includes a fixed header and a variable parameter section; wherein, the fixed header includes an instruction identifier, an instruction sequence number, an initialization flag, a data length, and a checksum; the variable parameter section includes parameter information corresponding to the instruction type, and the parameter information includes at least one of target path, service identifier, user identifier, session verification information, and timeout threshold.

[0059] Specifically, the fixed header of the instruction data is the unified basic structure for all types of instructions. Its core function is to establish the parsing rules between the communicating parties and to ensure the security and orderliness of data transmission. No matter how the instruction type changes, the composition and format of the fixed header fields always remain consistent.

[0060] Specifically, the instruction identifier is the identity label of the instruction, directly corresponding to the specific operation type such as starting a sandbox process, importing or exporting files, and submitting approvals, allowing the sandbox process to quickly identify the purpose of the instruction; the instruction sequence number is a unique identifier for each instruction, which can avoid duplicate processing or instruction reordering, and together with the host's retry policy, ensures communication reliability; the initialization flag is used to control the reset logic of shared memory, ensuring that the sandbox process is in an available state when the instruction is issued; the data length clearly specifies the number of bytes in the subsequent variable parameter part, avoiding data overflow or truncation during parsing; the checksum is used to verify the integrity of the instruction data, preventing tampering during transmission; these fields together constitute the fixed header of the instruction data, so that the host process and the sandbox process do not need to design separate parsing logic for different instructions, improving communication efficiency.

[0061] Specifically, the content of the variable parameter section changes dynamically with the instruction type, and is used to carry personalized information related to specific business, so as to realize one structure to adapt to multiple scenarios.

[0062] Specifically, the content of the variable parameter section is strongly bound to the instruction type: for example, file import / export instructions must include the target path and file summary; approval instructions must include a business identifier; all instructions involving access control must carry a user identifier and session verification information for the sandbox process to verify the legitimacy of the initiator; some instructions also need to include a timeout threshold to control the maximum execution time of the instruction. This design of carrying parameters on demand avoids memory waste caused by a fixed structure, eliminates the need to reserve redundant fields for all instructions, and only carries the information necessary for the current business, which not only simplifies the instruction data volume but also improves transmission efficiency, perfectly adapting to diverse business scenarios such as approval, file operation, and status notification between the sandbox process and the host process.

[0063] In one embodiment, before the host process writes instruction data into the first shared memory region, the method further includes: determining whether the initialization flag in the fixed header is set; if the initialization flag is set, resetting the data buffer of the first shared memory region, resetting the synchronization mechanism associated with the first shared memory region and the instruction sequence number, and waiting for the state of the sandbox process to become ready before performing the writing of the instruction data and the updating of the instruction status flag.

[0064] Specifically, when the host process issues an instruction, it determines whether the instruction is the first instruction after the sandbox process restarts, requires re-communication after an exception in the preceding instruction, or is a regular continuous instruction. If the instruction is the first instruction after the sandbox process restarts and requires re-communication after an exception in the preceding instruction, the initialization flag is set to data 1, informing the system to first clear the shared memory history state before establishing a clean instruction channel. If the instruction is a regular continuous instruction, the initialization flag remains unset, such as being set to data 0, directly skipping the reset process and improving communication efficiency. This on-demand triggering design ensures communication reliability in abnormal scenarios without affecting the transmission speed in normal scenarios.

[0065] Specifically, before the host process writes instruction data to the first shared memory region, it determines whether the initialization flag in the fixed header is set to decide whether to initialize and reset the first shared memory region, so as to avoid instruction transmission abnormalities due to historical state residues; wherein, the initialization flag is essentially a 1-bit control bit, and its core function is a state calibration switch.

[0066] Specifically, resetting the data buffer of the first shared memory region includes: clearing the circular buffer in the first shared memory region to remove residual instruction data or error information; resetting the synchronization mechanism associated with the first shared memory region includes: releasing and resetting the mutex associated with the first shared memory region to restore the initial available state of the mutex; and resetting the instruction sequence number includes: resetting the instruction sequence number to a predefined initial value.

[0067] Specifically, while waiting for the sandbox process to become ready, the channel status written by the sandbox process in the header field information of the first shared memory region is continuously monitored; only when the channel status is detected to switch from the initialization state or the recovery state to the ready state is it determined that the sandbox process has completed its own initialization and has the ability to receive instructions.

[0068] In one embodiment, when the host process writes instruction data into the first shared memory region, it first writes the fixed header sequentially according to a preset data format of fixed header and variable parameter section. The fixed header includes an instruction identifier, sequence number, initialization flag, variable parameter length, check value, and timestamp arranged in sequence. Then, according to the service type corresponding to the instruction identifier, the corresponding variable parameters are written. After the instruction data is written, the instruction status flag of the first shared memory region is updated from idle state to pending state to indicate that a new instruction has arrived.

[0069] Specifically, after writing the instruction data, the method further includes: calculating the checksum of the written instruction data, and adding the checksum to the fixed header or the variable parameter for data integrity verification.

[0070] As an example in this embodiment: when the host process writes instruction data into the first shared memory area, it first writes a fixed header: according to the field order agreed upon in the document, it sequentially fills in information such as instruction identifier, unique serial number, initialization flag, variable parameter length, check value, and timestamp; the length and encoding method of each field are fixed to ensure that the sandbox parses according to a unified rule and does not cause formatting errors; then, according to the business type corresponding to the instruction identifier in the fixed header, it fills in personalized parameters, such as the approval number for approval instructions, the target path for file export instructions, and the user identifier and session token for permission-related instructions. The parameter content fully matches the business requirements of the current instruction, without redundancy or omissions; after writing, it calculates and supplements the data checksum to ensure that the data is not tampered with or truncated during the writing process, providing a basis for the verification process on the sandbox side.

[0071] Specifically, after the instruction data is written, the host process updates the instruction status flag of the first shared memory region from the idle state (IDLE) to the pending state (PENDING). This pending state change is captured by the sandbox process's listening logic and becomes the core signal for the sandbox process to identify the arrival of new instructions. The host also triggers the event signal bound to the first shared memory region to quickly wake up the callback processing function on the sandbox side, replacing the sandbox's polling scan, further improving the real-time performance of instruction reception. After the writing and status update are completed, the host does not terminate the operation but continues to listen to the second shared memory region, waiting for the sandbox to execute the instruction and write back the result, preparing for subsequent callback processing or retry logic.

[0072] Step 103: When the sandbox process detects that the instruction status is marked as the first target status, it reads and executes the instruction data from the first shared memory area to generate result data.

[0073] In one embodiment, the first target state is a pending state.

[0074] In one embodiment, the sandbox process monitors the instruction status flags and channel sequence numbers in the first shared memory region.

[0075] Specifically, the sandbox process monitors the instruction status flags and channel sequence numbers in the first shared memory region. The core is to accurately capture new and valid instructions through double verification, avoiding the misprocessing of residual data or duplicate instructions. The onCommand callback function registered by the sandbox process is bound to the status bits and event signals of the first shared memory region. The monitoring is not an inefficient polling, but an event-driven real-time perception. When the host process writes an instruction and updates the status, it will trigger the corresponding event signal, directly waking up the monitoring logic of the sandbox process, balancing low latency and low resource consumption.

[0076] Specifically, the status flag is the core signal for whether an instruction is pending processing, and the sequence number is the unique identifier for whether an instruction is a new instruction. The combination of the two can avoid misjudging historical pending states as new instructions, and prevent duplicate processing caused by instruction retransmission or transmission delay, thus ensuring the accuracy of the monitoring logic.

[0077] In one embodiment, when the instruction status is detected to be in the pending state and the channel sequence number changes incrementally, the instruction status is updated to the executing state.

[0078] Specifically, when the sandbox process detects that an instruction status is marked as pending and the channel sequence number is incrementing, it immediately updates the status to "in execution." This step is a crucial transition from instruction reception to instruction execution, and its core function is to lock processing rights and synchronize the status. Logically, the pending status confirms that the host has issued a valid instruction, and the incrementing sequence number confirms that the instruction is a new, unprocessed instruction. After both conditions are met, the status is switched, which can send a signal to the host that the instruction has been received and is being processed, preventing the host process from repeatedly issuing instructions due to lack of feedback. At the same time, the channel's instruction status switching process is guaranteed to be atomic through a mutex lock, preventing multiple sandbox threads from simultaneously competing for instruction processing rights and ensuring the uniqueness and orderliness of instruction processing.

[0079] In one embodiment, the instruction data is read from and parsed from the first shared memory region, and the corresponding operation is performed.

[0080] Specifically, under the protection of a mutex lock, the sandbox process reads the instruction data from the first shared memory region and parses the instruction data according to a preset data format of fixed header and variable parameter section. The parsing process includes parsing the instruction data with a fixed header to obtain an instruction identifier, and extracting the business data in the variable parameter section of the instruction data based on the instruction identifier. Based on the parsed instruction identifier and the business parameters, the corresponding business operation is executed.

[0081] Specifically, parsing the instruction data also includes verifying the integrity of the instruction data based on the checksum in the fixed header.

[0082] Specifically, when performing corresponding business operations based on the parsed instruction identifier and business parameters, if the instruction identifier represents an approval instruction, then permission verification and approval result determination are performed based on the business parameters; if the instruction identifier represents a file operation instruction, then file path location and data processing are performed based on the business parameters.

[0083] In one embodiment, result data is generated based on the first execution result of the instruction data, wherein the result data includes at least a result code, a message type, and an impact approval list marker.

[0084] In one embodiment, generating result data based on the first execution result of the instruction data specifically includes: setting the result code in the result data as a success identifier, a failure identifier, or a retry identifier according to the execution status of the first execution result of the instruction data; setting the corresponding message type in the result data according to the instruction type corresponding to the instruction data; determining whether the first execution result causes a change in the core data status of the approval business, and if so, setting the impact approval list marker in the result data.

[0085] Specifically, the result code is the core field of the result data. Its value strictly corresponds to the execution status. Based on the execution status of the first execution result of the instruction data, the result code is set as a success identifier, a failure identifier, or a retry identifier. The core is to use standardized status codes to clearly feedback the execution result of the instruction to the host, providing a direct basis for subsequent processing logic.

[0086] Specifically, when the sandbox process completes all business operations as required by the instruction during execution without any exceptions, the result code is set to a success flag, informing the host that no further processing is needed. When the sandbox process encounters an unrecoverable error during instruction execution, causing the instruction data to fail to be completed, the result code is set to a failure flag, and an error description can be added to the result data to help the host process locate the problem. When the sandbox process encounters a temporary exception during instruction execution, and the instruction may succeed after the exception is resolved, the result code is set to a retry flag, triggering the host's preset retry policy. This classification design allows the host to quickly determine the direction of subsequent operations simply by using the result code, without needing to parse complex logs.

[0087] Specifically, based on the instruction type corresponding to the instruction data, the corresponding message type in the result data is set. The core is to establish a one-to-one association between instruction data and result data, so that the host can quickly assign result processing logic.

[0088] Specifically, the message type value is strongly bound to the command type. For example, if the host process issues a file import command, the corresponding message type after the sandbox process executes it will be set to file import result; if the host process issues an approval submission command, the corresponding message type after the sandbox process executes it will be set to approval processing result; if the host process issues a sandbox status query command, the corresponding message type after the sandbox process executes it will be set to status query feedback. This allows the host process to directly dispatch the result data to the corresponding processing branch based on the message type when it receives the result data. It can automatically perform operations such as interface update, cache synchronization, or log recording without additional judgment of the command source, which greatly improves the efficiency of result processing.

[0089] Specifically, it determines whether the first execution result causes a change in the status of the core data of the approval business. If so, it sets the affected approval list flag. The core is to trigger the host's approval data synchronization logic through a status change signal to ensure that the business data is eventually consistent.

[0090] Specifically, the core data status of the approval process includes at least one of the following: the approval status of the approval form, the approval permission configuration, and the approval process node. When the instruction data executed by the sandbox process directly changes the approval status, approval permission configuration, or approval process node, such as changing the approval status from pending to approved after the approval instruction is executed, or changing the scope of the approval permission configuration after the permission adjustment instruction is executed, it is considered that the core data status of the approval process has changed. In this case, the impact approval list flag will be set to 1. If the instruction execution process does not involve the approval status, approval permission configuration, or approval process node, such as a simple sandbox status query or a file operation without permission changes, it is considered that the core data status of the approval process has not changed, and the impact approval list flag will not be set, i.e., it will be set to 0. This impact approval list flag is the key basis for the host process to trigger approval list synchronization. When the host process detects that the impact approval list flag is set, it will automatically call the approval list query interface to synchronize the latest data to the local cache or database, so as to avoid users seeing outdated approval status due to data asynchrony.

[0091] Step 104: The sandbox process writes the result data into the second shared memory region and updates the result status flag of the second shared memory region.

[0092] In one embodiment, the sandbox process encapsulates the result data according to a predefined data format, and writes the encapsulated result data into the second shared memory region under the protection of a mutex lock to ensure the atomicity of the write.

[0093] In one embodiment, updating the result status flag of the second shared memory region means updating the result status flag from an idle state to a processing completed state or a processing failed state.

[0094] Specifically, before writing the result data, the result status flag in the second shared memory area is in an idle state; after the result data is written, the sandbox process updates it to either processing completed or processing failed; this status change is written to the header field information of the second shared memory area and stored in association with the result data; the core function of the result status flag is to synchronize the result processing progress: processing completed indicates that the result data is complete and valid, and the host can directly read and parse it; processing failed indicates that the result data is abnormal, prompting the host to perform error handling subsequently; this linkage design of data writing and status updating allows the host process to accurately determine whether the result data is ready simply by listening to the result status flag without polling and scanning, thus avoiding the host process reading incomplete data in advance.

[0095] In one embodiment, after updating the result status flag of the second shared memory region, the method further includes: triggering an event signal bound to the second shared memory region to wake up the corresponding callback processing function on the host side.

[0096] Specifically, updating the result status flag triggers an event signal bound to the second shared memory region, directly waking up the result callback function on the host side, replacing the traditional polling mode, and achieving immediate response to the result; this collaborative logic not only utilizes the high-speed transmission characteristics of shared memory to reduce result return latency, but also ensures that the host can accurately capture the result ready signal through the status synchronization mechanism, laying the foundation for subsequent host parsing of results, synchronization caching, or triggering retries.

[0097] In one embodiment, to address abnormal scenarios such as process restarts and event loss, shared memory communication can be combined with event signals and lightweight message queues to build a more reliable asynchronous communication mechanism.

[0098] Specifically, when the host process writes instruction data to the first shared memory area and the sandbox process writes result data to the second shared memory area, in addition to updating the corresponding status flags, it is also necessary to synchronously trigger preset named event signals, such as triggering the CmdArrival Event after the host writes an instruction and triggering the ResultArrival Event after the sandbox writes a result. The event signals quickly wake up the callback processing thread of the other end, replacing the traditional polling and further reducing the response latency.

[0099] Specifically, a lightweight message queue is introduced to record the sequence numbers of unprocessed instructions / results in the shared memory region. When the host process or sandbox process restarts abnormally, the unprocessed sequence numbers can be replayed from the message queue. By matching the sequence numbers, the unprocessed instruction or result data can be located in the shared memory region, avoiding message loss due to process restart. Simultaneously, the message queue periodically verifies with the status flags of the shared memory region to ensure that the sequence numbers in the queue match the instruction / result sequence numbers in the shared memory region that are pending or in the processing state, achieving state alignment between the shared memory and the message queue. This solution enhances the system's self-recovery capability in abnormal scenarios while retaining the low latency advantages of shared memory, making it particularly suitable for enterprise security management scenarios with extremely high requirements for communication reliability, such as sandbox malicious behavior alerts and sensitive file operation approvals.

[0100] Step 105: When the host process detects that the result status is marked as the second target status, it reads and executes the result data from the second shared memory region.

[0101] In one embodiment, when the host process detects that the result status flag of the second shared memory region has changed to a completed state, it reads the result data from the second shared memory region.

[0102] Specifically, the host process uses an event-driven mechanism to detect in real time the result status flag switching from an idle state to a completed state.

[0103] Specifically, before reading, the host process first acquires a mutex lock associated with the second shared memory region to avoid potential conflicts with subsequent operations of the sandbox process and ensure the atomicity of the read. During the read process, the host process will first verify the sequence number in the result data to determine whether the sequence number in the result data is consistent with the sequence number used when the host process issued the corresponding instruction. If the sequence number is completely consistent with the sequence number of the instruction issued by the host, the result number is read from the second shared memory region to prevent result corruption or duplicate processing.

[0104] In one embodiment, the host-side callback processing function is invoked, and a target processing operation matching the message type in the result data is performed based on the host-side callback processing function.

[0105] Specifically, after reading the result data, the message type in the result data is mapped to the corresponding host-side callback function according to the pre-built callback table to determine the host-side callback function to be called. The callback table stores the correspondence between message types and callback functions. The target processing operation matching the message type is executed through the host-side callback function.

[0106] Specifically, when executing a target processing operation matching the message type, if the result encoding in the result data indicates success, the user interface prompt is updated and a success log is recorded; if the result encoding indicates failure, an error message and a trigger notification are displayed; if the result encoding indicates retry, instruction data is rewritten to the first shared memory area according to a predefined retry strategy to achieve self-recovery in abnormal scenarios and ensure the real-time and targeted nature of result processing.

[0107] Specifically, if the corresponding instruction is reissued according to the predefined retry policy, the instruction data is reconstructed and written to the first shared memory area according to the preset number of retries and time intervals.

[0108] In one embodiment, when the impact approval list flag in the result data is set, an approval list synchronization operation is automatically initiated.

[0109] Specifically, after reading the result data, it is determined whether the impact approval list flag in the result data is set; if the impact approval list flag is set, an approval list synchronization operation is automatically initiated, wherein the synchronization operation includes calling the approval list query interface to obtain the latest approval data; and synchronizing the latest approval data to local storage.

[0110] Specifically, synchronizing the latest approval data to local storage means writing the latest approval data into the local cache and / or database.

[0111] Specifically, after the synchronization operation is completed, the approval list displayed in the user interface is also updated so that users can see the latest status in real time.

[0112] A brief example of the inter-process communication method based on shared memory provided in this application is given below: In the enterprise sandbox file export process, after a user submits an approval request, the host process issues an approval instruction to the first shared memory region and updates the instruction status mark of the first shared memory region to the pending state. When the sandbox process detects that the instruction status mark of the first shared memory region is marked as pending, it reads the approval instruction, executes the approval instruction, writes the approval result corresponding to the obtained approval instruction back to the second shared memory region, and updates the result status mark of the second shared memory region to the completed state. When the host process detects that the result status mark of the second shared memory region is marked as completed, it performs the corresponding operation on the read approval result based on the host-side callback processing function, automatically refreshes the approval list, and notifies the user, which can significantly shorten the feedback time of the approval status.

[0113] In one embodiment, the host process and sandbox process mentioned in this application are applicable to various deployment modes, such as stand-alone mode, virtualization scenario and containerization scenario.

[0114] Specifically, for standalone connection mode: the host service and sandbox module run on the same host, directly sharing memory, suitable for desktop terminals or single-node servers; for virtualization scenarios: the host service runs on the host machine, and the sandbox runs in a virtual machine, communicating via shared memory pass-through or shared memory services provided by the host; for containerization scenarios: in container orchestration platforms, shared memory is implemented through shared volumes or host machine memory mapping, and the protocol layer of this application does not need to be modified; during system operation, attention should be paid to shared memory permission settings to prevent unauthorized processes from reading and writing sensitive data; at the same time, the audit module records the initiator, parameters, and results of each instruction.

[0115] Example 2, see Figure 2 , Figure 2 This is a schematic diagram of an embodiment of an inter-process communication device based on shared memory provided in this application. Corresponding to the above-described inter-process communication method based on shared memory, this application also provides an inter-process communication device based on shared memory. This inter-process communication device based on shared memory includes modules for executing the above-described inter-process communication method based on shared memory. This inter-process communication device based on shared memory can be configured in terminals such as desktop computers, tablet computers, and laptops. Specifically, this inter-process communication device based on shared memory includes a bidirectional shared memory channel construction module 201, an instruction data writing module 202, an instruction data execution module 203, a result data writing module 204, and a result data execution module 205.

[0116] The bidirectional shared memory channel construction module 201 is used to construct a bidirectional shared memory channel between the host process and the sandbox process based on a first shared memory region and a second shared memory region.

[0117] The instruction data writing module 202 is used to write instruction data into the first shared memory region and update the instruction status flag of the first shared memory region.

[0118] The instruction data execution module 203 is used to read and execute the instruction data from the first shared memory area and generate result data when the instruction status is detected as the first target status.

[0119] The result data writing module 204 is used to write the result data into the second shared memory region and update the result status flag of the second shared memory region.

[0120] The result data execution module 205 is used to read and execute the result data from the second shared memory region when the host process detects that the result status is marked as the second target status.

[0121] In one embodiment, the bidirectional shared memory channel construction module 201 is used to construct a bidirectional shared memory channel between the host process and the sandbox process based on a first shared memory region and a second shared memory region. Specifically, this includes: when the host process starts, it creates the first shared memory region and the second shared memory region according to a preset name, writes corresponding header field information to the first shared memory region and the second shared memory region, and registers a host-side callback function for processing the result data; after the sandbox process starts, it maps the first shared memory region and the second shared memory region according to the preset name, sets the channel state of the bidirectional shared memory channel to a ready state, and registers a sandbox-side callback function for processing the instruction data; the host process and the sandbox process complete a handshake based on the header field information and the ready state to confirm the establishment of the bidirectional shared memory channel.

[0122] In one embodiment, the instruction data includes a fixed header and a variable parameter section; wherein, the fixed header includes an instruction identifier, an instruction sequence number, an initialization flag, a data length, and a checksum; the variable parameter section includes parameter information corresponding to the instruction type, and the parameter information includes at least one of target path, service identifier, user identifier, session verification information, and timeout threshold.

[0123] In one embodiment, before writing instruction data to the first shared memory region, the instruction data writing module 202 further includes: determining whether the initialization flag in the fixed header is set; if the initialization flag is set, resetting the data buffer of the first shared memory region, resetting the synchronization mechanism associated with the first shared memory region and the instruction sequence number, and waiting for the state of the sandbox process to become ready before performing the writing of instruction data and the updating of the instruction status flag.

[0124] In one embodiment, the instruction data execution module 203 is used to read and execute the instruction data from the first shared memory region and generate result data when the instruction status marker is detected to be a first target state. Specifically, this includes: the sandbox process monitoring the instruction status marker and channel sequence number in the first shared memory region; when the instruction status marker is detected to be the pending state and the channel sequence number changes incrementally, updating the instruction status marker to the executing state; reading and parsing the instruction data from the first shared memory region and performing corresponding operations; and generating result data based on the first execution result of the instruction data, wherein the result data includes at least a result code, message type, and an impact approval list marker.

[0125] In one embodiment, the instruction data execution module 203 is used to generate result data based on the first execution result of the instruction data, specifically including: setting the result code in the result data as a success identifier, a failure identifier, or a retry identifier according to the execution status of the first execution result of the instruction data; setting the corresponding message type in the result data according to the instruction type corresponding to the instruction data; determining whether the first execution result causes a change in the core data status of the approval business, and if so, setting the impact approval list marker in the result data.

[0126] In one embodiment, the result data execution module 205 is used to read and execute the result data from the second shared memory region when the result status marker is detected to be the second target status. Specifically, this includes: when the host process detects that the result status marker in the second shared memory region has changed to the completed status, it reads the result data from the second shared memory region; it calls the host-side callback processing function and executes a target processing operation matching the message type in the result data based on the host-side callback processing function; and when the impact approval list marker in the result data is set, it automatically initiates an approval list synchronization operation.

[0127] The shared memory-based inter-process communication device described above can implement the shared memory-based inter-process communication method of the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here.

[0128] like Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of a computer device provided in this application; it includes a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112 and the memory 113 communicate with each other through the communication bus 114, and the memory 113 is used to store computer programs.

[0129] In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the inter-process communication method based on shared memory provided in any of the foregoing method embodiments.

[0130] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0131] Therefore, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the inter-process communication method based on shared memory as provided in any of the foregoing method embodiments.

[0132] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0133] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0135] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0136] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0137] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0138] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Since these modifications and variations fall within the scope of the claims and their equivalents, this application also intends to include these modifications and variations.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for inter-process communication based on shared memory, characterized in that, Communication between host processes and sandbox processes includes: A bidirectional shared memory channel based on the first shared memory region and the second shared memory region is constructed between the host process and the sandbox process; The host process writes instruction data into the first shared memory region and updates the instruction status flag of the first shared memory region. When the sandbox process detects that the instruction status is marked as the first target status, it reads and executes the instruction data from the first shared memory area to generate result data. The sandbox process writes the result data into the second shared memory region and updates the result status flag in the second shared memory region; When the host process detects that the result status is marked as the second target status, it reads and executes the result data from the second shared memory region.

2. The method as described in claim 1 above, characterized in that, The construction of a bidirectional shared memory channel between the host process and the sandbox process, based on a first shared memory region and a second shared memory region, specifically includes: When the host process starts, it creates the first shared memory region and the second shared memory region according to a preset name, writes the corresponding header field information to the first shared memory region and the second shared memory region, and registers a host-side callback function for processing the result data. After the sandbox process starts, it maps the first shared memory region and the second shared memory region according to the preset naming, sets the channel status of the bidirectional shared memory channel to the ready state, and registers a sandbox-side callback processing function for processing the instruction data. The host process and the sandbox process complete a handshake based on the header field information and the ready status to confirm the establishment of the bidirectional shared memory channel.

3. The method as described in claim 2 above, characterized in that, The instruction data includes a fixed header and a variable parameter section; The fixed header includes an instruction identifier, an instruction sequence number, an initialization flag, a data length, and a checksum. The variable parameter section includes parameter information corresponding to the instruction type, and the parameter information includes at least one of the following: target path, service identifier, user identifier, session verification information, and timeout threshold.

4. The method as described in claim 3 above, characterized in that, Before the host process writes the instruction data to the first shared memory region, it also includes: Determine whether the initialization flag in the fixed header is set; If the initialization flag is set, the data buffer of the first shared memory region is reset, the synchronization mechanism associated with the first shared memory region and the instruction sequence number are reset, and the writing of the instruction data and the updating of the instruction status flag are performed after the state of the sandbox process becomes ready.

5. The method as described in claim 3 above, characterized in that, When the sandbox process detects that the instruction status is marked as the first target status, it reads and executes the instruction data from the first shared memory region to generate result data, specifically including: The sandbox process monitors the instruction status flags and channel sequence numbers in the first shared memory region; When the instruction status is detected to be in the pending state and the channel sequence number changes incrementally, the instruction status is updated to the executing state. Read and parse the instruction data from the first shared memory region, and execute the corresponding operation; Result data is generated based on the first execution result of the instruction data, wherein the result data includes at least the result code, message type, and impact approval list marker.

6. The method as described in claim 5 above, characterized in that, The generation of result data based on the first execution result of the instruction data specifically includes: Based on the execution status of the first execution result of the instruction data, the result code in the result data is set to a success identifier, a failure identifier, or a retry identifier; Based on the instruction type corresponding to the instruction data, set the corresponding message type in the result data; Determine whether the first execution result causes a change in the core data status of the approval business. If so, set the affected approval list flag in the result data.

7. The method as described in claim 6 above, characterized in that, When the host process detects that the result status is marked as the second target status, it reads and executes the result data from the second shared memory region, specifically including: When the host process detects that the result status flag of the second shared memory region has changed to a completed state, it reads the result data from the second shared memory region. Invoke the host-side callback function, and perform a target processing operation that matches the message type in the result data based on the host-side callback function; When the "Affected Approval List" flag in the result data is set, an approval list synchronization operation is automatically initiated.

8. An inter-process communication device based on shared memory, characterized in that, It is used for communication and transmission between host processes and sandbox processes, including: bidirectional shared memory channel construction module, instruction data writing module, instruction data execution module, result data writing module and result data execution module; The bidirectional shared memory channel construction module is used to construct a bidirectional shared memory channel between the host process and the sandbox process based on a first shared memory region and a second shared memory region. The instruction data writing module is used to write instruction data into the first shared memory region and update the instruction status flag of the first shared memory region. The instruction data execution module is used to read and execute the instruction data from the first shared memory area and generate result data when the instruction status is detected as the first target status. The result data writing module is used to write the result data into the second shared memory region and update the result status flag of the second shared memory region; The result data execution module is used to read and execute the result data from the second shared memory region when the host process detects that the result status is marked as the second target status.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-7.

Images