JP2007299319A - Information processor and process-to-process communication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce the consumption of a memory resource by allowing easy management of identifiers of objects for process-to-process communication. <P>SOLUTION: This information processor is provided for operating a plurality of processes. Each process relating to data communication consists of a receiving means for receiving information for the identifiers of the data transmission objects relating to a data communication path from other processes, and a connection establishing means for establishing the connection to the other processes using the data transmission objects to be identified by the identifiers received by the receiving means. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to an information processing apparatus and an interprocess communication method.

  In a computer system, an IPC (Inter Process Communication) function for transmitting and receiving messages between processes is generally provided as a part of an operating system (Operating System) function. Although the detailed implementation varies depending on the operating system, there are a shared memory, a message queue, a semaphore, and the like as available means.

  In IPC, a virtual data transport path that connects processes to each other is a data object called an IPC object. When communication is performed, both processes that are to communicate communicate with each other to share information on the identifiers of the IPC objects that are used by each other, and the same identifier is specified by both of them to establish a communication connection. In other words, it is an indispensable work when sending and receiving messages by IPC that programs for sending and receiving messages share the same IPC object identifier.

  The conventional method for sharing the identifier of the IPC object between different processes can be roughly divided into two.

  The first method is a method in which a keyword character string is determined and shared among programs that perform IPC. In general, in a system that provides an IPC function, a function for querying an identifier of an IPC object based on a keyword is also provided. Therefore, an identifier of an IPC object secured by one process is also queried by a keyword from another process. It is possible. In this method, an IPC object identifier can be shared at the time of execution by arranging a required number of keywords in advance between programs using the IPC.

  The second method is a method in which all IPC connections used in the system are identified in advance, all IPC objects and their identifiers are secured in advance, and a program is created to use them.

JP 2003-124969 A

  However, the first and second methods described above have some problems. In the first method, generally, the strictness is not guaranteed in the function of collating the identifier of the IPC object from the keyword. For this reason, for example, different IPC object identifiers may be returned as matching results even with the same keyword.

  For this reason, it is essential to implement a function for confirming whether the collated IPC object identifier is really intended. A further problem is the complexity of keyword management. One keyword is required for one communication path. Therefore, when the number of program modules for performing IPC increases, or when there are a plurality of IPC connections even if the number of program modules is small, the number of keywords that must be shared is also proportional to this. Become more. This complicates the procedure that individual program modules must perform to share keywords. As a result, the prospects of the program module and the entire system are deteriorated, which causes deterioration of maintainability.

  On the other hand, since all the IPC objects and their connections are determined in advance, the second method is superior in performance because it does not require a step of checking IPC object identifiers between processes during operation. However, there is a problem that it cannot be applied to a system that needs to dynamically secure an IPC object and connection during operation.

  In addition, since the memory resources are consumed to secure the IPC object, the method of securing all of the IPC objects in advance, the lower limit value of the amount of memory resources required by the system depends on the number of IPC connections in the system. End up. Therefore, as the number of connections increases, more memory resources are required. For this reason, it is difficult to apply to devices that have only a small amount of memory resources.

  The present invention has been made in view of the above-described problems, and it is an object of the present invention to facilitate the management of object identifiers related to interprocess communication and to reduce the consumption of memory resources.

  Therefore, in order to solve the above problem, the present invention is an information processing apparatus capable of operating a plurality of processes, and each process related to data communication notifies the identifier of the data transmission object related to the data communication path. Receiving means from another process, and connection establishing means for establishing a connection with the other process using the data transmission object identified by the identifier received by the receiving means. And

  According to the present invention, by adopting such a configuration, it is possible to easily manage object identifiers related to inter-process communication, and to suppress consumption of memory resources.

  Moreover, in order to solve the said problem, this invention is good also as an interprocess communication method, a program, and a recording medium.

  According to the present invention, management of object identifiers related to inter-process communication can be facilitated, and consumption of memory resources can be kept low.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  Immediately before starting the message transmission / reception by the IPC, the process to start the IPC notifies the IPC object identifier used in the IPC to the other party performing the IPC. The process receiving the notification uses the IPC object having the notified identifier. The IPC connection is established in this way, and after the IPC is finished, the IPC object used by the process that started the IPC or a process with appropriate authority is discarded.

  FIG. 1 is a diagram showing a basic configuration of each embodiment described below. The apparatus according to the present embodiment (which will be described below using an information processing apparatus as an example) operates when the program module group 11 and one or a plurality of execution objects created from one or a plurality of programs are operated. And a process group 16 including a plurality of processes 17. The information processing apparatus also includes a communication path group 18 including an IPC object (hereinafter also referred to as a communication path) 19 used in IPC.

  The program module group 11 includes modules that implement some means. The module 12 is a module having means for specifying and selecting a notification destination process when notifying an IPC object identifier (hereinafter also referred to as a communication path identifier) to a process of the other party who is going to perform IPC. .

  The module 13 is a module having means for transmitting the identifier of the communication path as data to the process specified and selected by the module 12. The module 14 is a module provided with means for receiving the notified communication path identifier data. The module 15 is a module having means for designating the notified communication path identifier data to be used in the IPC to be performed.

  FIG. 2 is a flowchart showing the principle processing of each embodiment shown below. In FIG. 2, the process from the start to the end of the IPC is shown in each step. A process that calls another process to perform IPC is hereinafter referred to as a first process. The called process that starts the IPC with the first process in response to a request from the first process is hereinafter referred to as a second process.

  When performing IPC between the first process and the second process, first, the first process secures a communication path to be used and acquires its identifier (step S21). Next, the first process notifies the second process of the identifier of the communication path secured in step S11 (step S22).

  When the second process receives the notification from the first process (step S23), it starts the IPC start procedure. At this time, the second process sets to use the communication path specified by the identifier notified from the first process (step S24).

  Thereafter, the first process and the second process perform message transmission / reception by IPC (step S25). When the message transmission / reception is completed and the IPC communication path is no longer required, the first process or a process having appropriate authority discards the used communication path (step S26).

<Embodiment 1>
FIG. 3 is a diagram illustrating an example of a hardware configuration of the information processing apparatus. As shown in FIG. 3, the information processing apparatus includes, as a hardware configuration, an input unit 110, a display unit 120, a recording medium drive unit 130, a ROM 150, a RAM 160, a CPU 170, an interface unit 180, and an HD 190. And including. Here, ROM is an abbreviation for Read Only Memory. RAM is an abbreviation for Random Access Memory. CPU is an abbreviation for Central Processing Unit. HD is an abbreviation for Hard Disk.

  The input unit 110 includes a keyboard and a mouse operated by an operator (or user) of the information processing apparatus, and is used to input various operation information and the like to the information processing apparatus. The display unit 120 includes a display used by an operator of the information processing apparatus, and is used to display various types of information (or screens). The interface unit 180 is an interface that connects the information processing apparatus to a network or the like.

  A program that provides a function to be described later is provided to the information processing apparatus by a recording medium 140 such as a CD-ROM, or downloaded through a network or the like. The recording medium 140 is set in the recording medium drive unit 130, and the program is installed from the recording medium 140 to the HD 190 via the recording medium drive unit 130.

  The ROM 150 records a program that is read first when the information processing apparatus is powered on. The RAM 160 is a main memory of the information processing apparatus. The CPU 170 reads out a program from the HD 190 as necessary, stores it in the RAM 160, and executes the program, thereby providing all or part of the functions described below, or executing a flowchart described below. In addition to the program, the HD 190 may store, for example, shared communication path information 32, a message system definition 33, a component identifier definition 34, and the like which will be described later.

  FIG. 4 is a first diagram illustrating an example of a functional configuration of the information processing apparatus. The information processing apparatus has, as a functional configuration, a program module group 35 including one or a plurality of program modules 351 including a functional module 3511, an IPC object (hereinafter also referred to as a shared communication path) 36 accessible from any process, and the like. Have. In addition, the information processing apparatus has, as functional configurations, shared communication path information 32 that is information of the shared communication path 36, a shared communication path management module 31 that manages the shared communication path 36, and a program module 351 that performs IPC. And a runtime communication channel group 37 to be used. In addition, the information processing apparatus includes a component identifier definition 34 for identifying the program module 351 and a message system definition 33 for defining a procedure up to establishing an IPC connection as functional configurations.

  The program module 351 is a group of program modules for realizing a specific service, and its processing unit is shown as a function implementing unit 3512 for each module in FIG. That is, the program module 351 includes a function realization unit 3512 for each module and a module 3511 related to inter-process communication. Note that the inter-process communication in this embodiment refers to message transmission / reception between processes generated when the program module 351 is executed.

  In the present embodiment, it is assumed that a procedure necessary for establishing an IPC connection between the program modules 351 is defined in the message system definition 33. After the message defined in the message system definition 33 is exchanged via the shared communication path 36 from the process that wants to start IPC to the partner process that wants to perform IPC, IPC is started. Further, the process identifies the process of the other party to whom IPC is to be performed by the component identifier definition 34. Here, the shared communication path 36 is generated by the shared communication path management module 31. A message queue is used in the shared communication path.

  Next, the operation of the information processing apparatus will be described together with the detailed operation of each component. First, the message system definition 33 and the component identifier definition 34 will be described.

  The message system definition 33 and the component identifier definition 34 are defined in advance before the system is started and stored in the HD 190 or the like. The component identifier definition 34 is a table defined in advance so that processes can identify themselves and each other during system operation.

  FIG. 5 is a diagram illustrating an example of the component identifier definition 34. The component identifier definition 34 includes a program module name 61, a process 62 to be generated, and an identifier 63. Here, the program module name is information on the program module. The process to be generated is information on the number of processes that can be generated by the program module. The identifier is an identifier assigned to those processes.

  In FIG. 5, for example, the program module “http server” is designed to be able to generate four child processes in addition to the main process, and identifiers “0x0010” to “0x0014” are assigned to these five processes. Is assigned.

  In this embodiment, the component identifier definition 34 is described in the program source so that the execution object has information defined in the component identifier definition 34. However, the component identifier definition 34 may be stored in a text file, a shared memory, or the like, and the component identifier definition 34 or information defined in the component identifier definition 34 may be read when the program is executed.

  Next, an example of the message system definition 33 is shown in FIG. FIG. 6 is a diagram illustrating an example of the message system definition 33. The message system definition 33 includes a message type definition 71, a data format definition 72, and a message usage rule definition 73.

  The message type definition 71 defines a procedure (message) type (meaning of a message) used in the process of starting IPC, an identifier for identifying the message type, and argument data included in the message.

  In the message type definition 71 shown in FIG. 6, two types of “start request” (711) and “start request response” (712) are defined. The start request 711 is a message for notifying the process that is desired to perform IPC. The start request 711 is a message for transmitting an identifier of a communication path to be used. The start request response 712 is a message for returning, to the process that issued the request, whether the process that received the start request accepts or rejects the start of the IPC. That is, the start request response 712 includes an acceptor or reject identifier.

  In the data format definition 72, a format of data expressing the message type definition 71 is defined. In the data format definition 72 of the present embodiment, a 10-byte memory area is used to convey a message, and a transmission source identifier, a transmission destination identifier, a message type identifier, and argument data are stored in order from the top. Has been.

  The message usage rule definition 73 defines a message usage method, such as a message issuer and the order of messages.

  FIG. 7 shows an example of message data transmitted when the authentication main process makes an IPC start request to the child process 1 of the storage Web service using the communication path “0x003F”. FIG. 7 is a diagram illustrating an example of message data.

  As shown in FIG. 5, the user authentication main process is “0x0030”, and the child process 1 of the storage Web service is “0x0021”. Also, from FIG. 6, the message type identifier of the start request is “0x01”, and the communication channel identifier is stored in the data of the start request message. Therefore, in the example of FIG. 7, the message data stores “0x0030” (81), “0x0021” (82), “0x01” (83), and “0x003F” (84) from the top of the memory.

Next, the flow of processing from the start to the end of the information processing apparatus will be described.
First, a mechanism for generating and deleting the shared communication path 36 used for the IPC connection process will be described, and then a more specific procedure of the IPC connection process will be described.

  FIG. 8 is a flowchart illustrating an example of processing related to generation / deletion of a shared communication path. After the information processing apparatus is activated, the shared communication path management module 31 is activated first (step S41). The activated shared communication path management module 31 creates a message queue that can be read and written by any process (step S42). The message queue created here becomes a shared communication path 36 used by each process in the subsequent exchange.

  Further, the shared communication path management module 31 describes the created message queue identifier (IPC object identifier value) in a file readable by any process (step S43). In the present embodiment, the shared communication path management module 31 stores the value of the identifier of the IPC object in a text file so that it can be read from any process.

  FIG. 9 is a diagram illustrating an example of a text file in which the identifier value of the IPC object is stored. In the example of FIG. 9, the identifier is “0x003F”, and the identifier 52 is stored in the file 51.

  Note that the essence of the processing in step S43 is that other processes can know the identifier of the shared communication path 36, and the method of writing to the file system and the way of writing are not essential. For example, the shared communication path management module 31 may store the identifier value of the IPC object at a predetermined shared memory (shared memory) address.

  Subsequently, for example, the information processing apparatus starts a process of each program module constituting the service. And each process performs each operation | movement (step S44). At the end of the system in the information processing apparatus, the shared communication path management module 31 deletes the message queue object used as the shared communication path 36 (step S45).

  Next, the procedure of the IPC connection process of the present invention will be described. First, the configuration and role of the functional module (3511 in FIG. 4) for realizing the IPC connection processing described above will be described, and then the operation will be described.

  First, FIG. 10 shows a configuration example of functional modules for realizing the procedure of IPC connection processing. FIG. 10 is a diagram illustrating an example of a functional module configuration. The initial setting unit 91 is a module that operates when a process is started and sets necessary information inside the process. The external information reference unit 92 is a module for externally referring to information such as an identifier of the shared communication path 36. The information storage unit 93 is a module for holding information such as the shared communication path 36 during the operation of the process.

  The message transmission unit 94 and the message reception unit 95 are modules that realize data transmission and reception by IPC, respectively. The connection message processing unit 96 is a module that realizes a function for generating and interpreting a message based on the message system definition 33 and a function for managing the state transition of the IPC connection process. The IPC connection processing unit 97 is a module that performs IPC between processes using a designated communication path identifier.

  Next, a process for IPC connection processing will be described. In this embodiment, in order to perform IPC connection processing, each process performs initial processing determined at the time of activation. FIG. 11 is a flowchart illustrating an example of initial processing of each process.

  First, the information storage unit 93 stores information on identifiers defined in its own process in the component identifier definition 34 (step S101). Next, the external information reference unit 92 reads the identifier of the shared communication path 36, and the information storage unit 93 stores this information (step S102). Finally, the message receiving unit 95 starts polling for waiting for a message (step S103). The process receives only when a message addressed to itself is entered in the shared communication path 36.

  FIG. 12 is a diagram (part 1) illustrating an example of the IPC connection process. First, the first process secures a runtime communication path to be used for IPC with the second process to be performed (step S1101). Then, the first process stores the identifier of the reserved runtime communication path (step S1102).

  The purpose of the processing in step S1101 and step S1102 is to secure a communication path to be used in IPC with the second process to be performed in the future, and a new communication path is created or an existing communication path is used. It doesn't matter what you do. When an existing communication path is used, the first process may acquire and store the identifier.

  Next, the first process refers to the component identifier definition and obtains the identifier of the second process. Further, the first process creates a start request message according to the message system definition 33, and transmits the data to the second process by designating the identifier of the shared communication path 36 (step S1103). The second process selects and receives the message addressed to itself which the first process has put in the shared communication path 36 (step S1104).

  FIG. 13 shows an example of message transmission / reception program codes related to the processing in steps S1103 and S1104. FIG. 13 is a diagram illustrating an example of a program code for message transmission / reception. Note that the example of FIG. 13 is an example in the case of using a SystemV message queue.

  In addition to the format of the message system definition 33, the component identifier of the second process is added to the data transmitted by the first process as a flag for facilitating selective reception of the message (first process). Example program 1201) executed in

  The second process uses the flag data as a filter to determine whether or not it is its own message and receives it (program example 1202 executed in the second process).

  The reception process on the shared communication path 36 is a process operation started in the initial process operation (step S103 in FIG. 11) described above.

  The second process that has received the IPC start request from the first process extracts the identifier of the communication path specified by the first process, contained in the received message, and uses the identifier as the IPC with the first process. (Step S1105). Subsequently, the second process creates a start request response message in accordance with the message system definition 33, specifies the identifier of the shared communication path 36, and transmits the data (step S1106). The first process receives the start request response message transmitted by the second process (S1107).

  Through the above processing, the identifier information of the communication path to be used is shared between the first process and the second process, an IPC connection is established, and a message (or data) is exchanged (S1108). .

  When the IPC between the first process and the second process ends, for example, the first process deletes the runtime communication path used (step S1109).

  In the above-described process, only one communication path is used in the IPC between the first process and the second process, but the same process is performed to multiplex the communication paths. it can.

<Embodiment 2>
In the second embodiment, an example of starting IPC between processes without using a shared communication path will be described. In the second embodiment, for the sake of simplicity, the description will be made using process words instead of program modules.

  FIG. 14 is a second diagram illustrating an example of a functional configuration of the information processing apparatus. The information processing apparatus has, as functional configurations, a runtime communication path group 1301 used when the processes 1305 perform IPC, and a message system definition 1302 that defines a procedure until IPC connection establishment. Further, the information processing apparatus has, as functional configurations, a component identifier definition 1303 for identifying the process 1305 and a process group 1304 including a process 1305 including a program module for IPC connection processing.

The above configuration is the same as that of the first embodiment.
In this embodiment, one reception-only communication path 1306 is assigned to each process 1305. The reception-only communication path 1306 is used as a communication path for sending a message to each process 1305.

  The reception-only communication path 1306 is secured by initial processing when a process is generated, and then the process waits for a message from the reception-only communication path 1306. Here, another process needs to know the identifier of the reception-only communication path 1306 of each process. Therefore, the component identifier definition 1303 obtains information on the identifier of the dedicated reception channel from the process identifier shown in FIG. 15 in addition to the table for identifying the same process as that in FIG. 5 of the first embodiment. Have a table that can.

FIG. 15 is a diagram illustrating an example of a table associating process identifiers with identifiers of the reception-only communication path 136.
141 is an identifier of the process indicated by 63 in FIG. 5, and 142 is an identifier of the reception-only communication path 136 of the process. When the process secures the reception-only communication path 136, the process records the identifier information of the reception-only communication path 136 in the table shown in FIG.

  This embodiment is similar to the example in which all the IPCs used in the system are defined in advance, as described in the second example of the background art, because each process has a reception-only communication path 136. However, according to the present embodiment, the difference is that even an IPC between processes that does not define an IPC object at the time of system design can operate.

  The IPC connection process in this embodiment will be described with reference to FIG. FIG. 16 is a second diagram illustrating an example of the IPC connection process. First, the first process secures a runtime communication path to be used in IPC with the second process to be performed (step S151). Then, the first process stores the identifier of the reserved runtime communication path (step S152).

  Next, the first process refers to the component identifier definition 1303, acquires the identifier of the second process, and acquires the identifier of the reception-only communication path 1306 of the second process from the identifier of the second process. In addition, the first process creates a start request message according to the message system definition 1302, designates the identifier of the reception-only communication path 1306 assigned to the second process, and transmits the data (step S153). .

  After receiving the start request message, the second process extracts the identifier of the communication path designated by the first process included in the message, and stores the identifier for use in the IPC with the first process. (Step S154). After step S153, the second process creates a start request response message in accordance with the message system definition 1302, designates the identifier of the reception-only communication path 1306 of the first process, and transmits the data (step S155). . The first process confirms that the second process has responded to the IPC start.

  With the above processing, the identifier information of the communication path to be used is shared between the first process and the second process, a direct IPC connection is established, and messages (or data) are exchanged. (S156).

  When the IPC between the first process and the second process ends, for example, the first process deletes the runtime communication path used (step S157).

  In the above-described process, only one communication path is used in the IPC between the first process and the second process, but the same process is performed to multiplex the communication paths. it can.

  As described above, according to each of the above-described embodiments, it is possible to easily manage object identifiers related to inter-process communication, and to reduce consumption of memory resources.

  The preferred embodiments of the present invention have been described in detail above, but the present invention is not limited to such specific embodiments, and various modifications can be made within the scope of the gist of the present invention described in the claims.・ Change is possible.

It is a figure which shows the fundamental structure of each embodiment shown below. It is a flowchart which shows the fundamental process of each embodiment shown below. It is a figure which shows an example of the hardware constitutions of information processing apparatus. FIG. 3 illustrates an example of a functional configuration of an information processing apparatus (part 1); 5 is a diagram illustrating an example of a component identifier definition 34. FIG. 6 is a diagram illustrating an example of a message system definition 33. FIG. It is a figure which shows an example of message data. It is a flowchart which shows an example of the process regarding the production | generation / deletion of a shared communication path. It is a figure which shows an example of the text file in which the value of the identifier of an IPC object was stored. It is a figure which shows an example of a structure of a functional module. It is a flowchart which shows an example of the initial process of each process. FIG. 10 is a diagram (part 1) illustrating an example of an IPC connection process; It is a figure which shows an example of the program code of message transmission / reception. FIG. 3 illustrates an example of a functional configuration of the information processing apparatus (part 2); It is a figure which shows an example of the table which associates the identifier of a process, and the identifier of the communication channel 136 only for reception. FIG. 10 illustrates an example of an IPC connection process (part 2);

Explanation of symbols

110 Input unit 120 Display unit 130 Recording medium drive unit 140 Recording medium 150 ROM
160 RAM
170 CPU
180 interface unit 190 HD

Claims (9)

An information processing apparatus capable of operating a plurality of processes,
Each process related to data communication
Receiving means for receiving a notification of the identifier of the data transmission object related to the data communication path from another process;
Connection establishment means for establishing a connection with the other process using the data transmission object identified by the identifier received by the receiving means;
An information processing apparatus comprising:   The information processing apparatus according to claim 1, wherein each process related to data communication further includes notification means for notifying another process of the communication partner of the identifier.   The information processing apparatus according to claim 1, wherein each process related to data communication further includes a selection unit that selects another process of the communication partner.   4. The selection unit refers to process identification definition information for identifying each process related to data communication, and identifies and selects another process of a communication partner from a plurality of other processes. The information processing apparatus described in 1.   5. The information processing apparatus according to claim 1, further comprising: a discarding unit that discards the data transmission object when data communication ends.   6. The information processing according to claim 1, wherein the receiving unit or the notification unit refers to notification definition information related to the notification of the identifier, and performs a process related to the notification of the identifier. apparatus. An inter-process communication method in an information processing apparatus capable of operating a plurality of processes,
A receiving step in which a process related to data communication receives a notification of an identifier of a data transmission object related to a data communication path from another process;
A connection establishment step in which the process related to the data communication establishes a connection with the other process using the data transmission object identified by the identifier received in the receiving step;
An interprocess communication method characterized by comprising:   A program for causing a computer to execute the interprocess communication method according to claim 7.   A computer-readable recording medium on which the program according to claim 8 is recorded.

Images