JP2003162419A - Apparatus having inter-process communication function - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an apparatus with inter-process communication functions among, capable of achieving a variable architecture and a variety of functions. <P>SOLUTION: In the apparatus comprising user service and processes of control service relating to performing processes and communication functions among processes, where each process operates as a server process 202 or a client process 201, the server process 202 has the functions of defining one or plural services to be provided to the client process 201; when requesting providing of service to the server process 202, the client process 201 calls the functions to achieve the above described purpose. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a device having an interprocess communication function, and more particularly to a device in which a plurality of processes perform interprocess communication as a server process or a client process.

[0002]

2. Description of the Related Art In recent years, an image forming apparatus (hereinafter referred to as a "multifunction machine") in which the functions of various devices such as a printer, a copier, a facsimile, and a scanner are housed in a single housing is generally known.

This multi-function machine is provided with a display unit, a printing unit, an image pickup unit, and the like in one housing, and three types of software corresponding to the printer, the copying machine, and the facsimile machine, respectively. Is operated as a printer, a copier, a scanner or a facsimile machine.

In a conventional multi-function peripheral, software (including a general-purpose OS) corresponding to a printer, a copier, a scanner, and a facsimile machine is separately provided inside, and it takes a lot of time to develop each software. .

Therefore, the applicant commonly uses a software group called a driver for driving a hardware interface, a manager software group for efficiently using common hardware assets such as a memory / timer, and each application. Multi-function machine equipped with a system utility software group that can be used for printers, scanner software, FAX transmission / FAX reception, etc. that uses these driver software group, manager software group, and utility software group. JP-A-9-51398,
(See Japanese Patent Application Laid-Open No. 9-91102).

However, in the multifunction machines described in Japanese Patent Laid-Open Nos. 9-51398 and 9-91102, a driver software group, a manager software group, and a utility software group are composed of libraries. , Could not be the entity that controls the execution of hardware resources.

Therefore, the applicant has hardware resources used for image forming processing such as a display section, a printing section, and an image pickup section, and performs processing unique to each user service such as a printer, copy, or facsimile. When a plurality of applications are installed and the user services are provided by intervening between these applications and hardware resources, management of hardware resources, execution control, and images commonly required by at least two of the applications are provided. Multifunction machine equipped with a platform consisting of various control services for performing formation processing (Japanese Patent Laid-Open No. 2002-82)
806).

[0008] The user service is a service relating to image formation provided to the user. The control service is a service that provides an application with hardware resources related to image formation.

According to this multi-function peripheral, the efficiency of software development is improved by providing a platform for performing management of hardware resources, execution control, and image forming processing commonly required by at least two applications. In addition, it is possible to improve the productivity of the entire device.

[0010]

In such a multi-function peripheral, at least two of the applications have a control service that provides a service commonly required. Therefore, the function change, the function addition, or the future In order to flexibly deal with the addition and modification of specific hardware resources, it is desirable to be able to easily add and modify each application or each control service. Further, when providing a composite service, it is necessary to smoothly exchange services and data between each application and each control service, or between each control service.

That is, the multi-function machine is a printer, a copy machine,
It has various functions such as a facsimile and a scanner, but if some of the functions fail or specifications change, all applications or all control service modules must be modified. The work effort becomes excessive.

Further, in the future, even when a new function is added to the multi-function peripheral, if it is necessary to change the modules of all control services and all applications in order to add some of the functions, the labor of program development will be increased. It becomes too large. For this reason, it is necessary that each application or control service module operating on the multi-function peripheral realizes mutual transmission and reception of services and data, while maintaining independence between modules.

That is, if there is no independence for each application or each control service, it becomes difficult to provide only the necessary application or necessary control service, and it is possible to flexibly deal with the function change and function addition. The configuration of can not be variable.

If there is no independence for each application or each control service, it becomes difficult to design and construct each application or control service, and it is impossible to provide various functions.

The present invention has been made in view of the above,
It is an object of the present invention to obtain a device having an interprocess communication function capable of realizing a variety of architectures and various functions.

[0016]

In order to achieve the above object, the invention according to claim 1 comprises a hardware resource according to a process to be executed, and a process of a user service and a control service related to the process. And a device having an inter-process communication function for the process, wherein each of the processes operates as a server process or a client process, and the server process provides one or more services to the client process. Is defined, and the client process calls a function when requesting the server process to provide a service.

According to the first aspect of the invention, it is possible to realize interprocess communication by calling a function between one or a plurality of user services and control services.

Therefore, in a device having a control service that provides a service common to the user service and the control service, the services and data are exchanged between processes while maintaining the independence between each user service and each control service. It is possible to provide a device that can be realized by communication and is functionally diverse.

Further, even when only some modules of the user service and control service are changed, or when the user service or control service is added as needed, the function is implemented on the module side which is the server process, Services and data can be sent and received by securing an interface for calling functions on the module side that is the client process.

Therefore, it is possible to easily add or change the user service or the control service, and it is possible to configure a device having variability.

Furthermore, since each of the user service and the control service is a process that operates as a server process or a client process, by operating a plurality of user services and a plurality of control services as separate processes, other users If a service or other control service process is stopped, other running processes are not affected.

Therefore, even if some processes are stopped, other composite services can be continuously provided,
It is possible to prevent all complex services from being unavailable.

Here, the "server process" means a process that provides a requested service in response to a request from another process, and as long as the service is provided, both the user service and the control service operate as a server process. can do.

The "client process" is a process that receives a service from such a server process, and as long as the service is provided, both the user service and the control service can operate as a client process. .

The "function" is to execute the processing or setting requested by the server process in response to a service processing request to the server process or a setting request of a predetermined setting value by the server process.

In the invention according to claim 2, the control service operates as a server process having the user service as a client process, and defines a service commonly required by at least two of the user services. The user service has a function, and calls the function when the user service requests the control service to provide the service.

According to the second aspect of the present invention, the provision of the service from the control service to the user service can be realized by inter-process communication by calling a function. For example, variability using the user service such as an application and It is possible to provide a variety of devices.

In the invention according to claim 3, the control service operates as a server process having another control service as a client process, and a service commonly required by at least two of the other control services. Is defined, and the other control service makes a function call when requesting the control service to provide the service.

According to the third aspect of the present invention, provision of services between control services can be realized by interprocess communication by function call, and provision of a device having variability and diversity using the control services. Is possible.

The invention according to claim 4 is characterized in that the control service operates as the server process and also as the client process.

According to the invention of claim 4, the bidirectional service provision between the user service and the control service and the bidirectional service provision between the control services are realized by interprocess communication by function call. Therefore, it is possible to provide a device with more variability and variety.

Further, the invention according to claim 5 is characterized in that each process of the user service and the control service includes one or a plurality of threads.

According to the fifth aspect of the present invention, it is possible to allocate functions that do not need to operate independently to a plurality of threads in the same process and execute them in parallel. Also, switching of execution control on a thread-by-thread basis does not require switching of the main memory space because it shares the main memory space, and can be achieved only by switching with less overhead such as switching of counters and registers, so a separate main memory space is used. As compared with the process unit switching that requires switching of the main storage space, the switching overhead is small.

Therefore, by activating one or a plurality of threads in each process of the user service and the control service to perform parallel execution, it is possible to improve the processing speed during parallel execution of the services.

In the invention according to claim 6, when the user service and the control service operate as the client process, the reception of a function return value for a function call to the server process is monitored and received. It is characterized by comprising a client monitoring means for delivering the function return value to the thread that has called the function.

According to the sixth aspect of the invention, the thread that has called the function from the client process waits for the next instruction execution until the function return value is passed by the client monitoring means. Other threads can get execution rights and can perform parallel operations.

Therefore, while starting a plurality of threads in a process and performing inter-process communication, other threads in the process can operate by waiting for a return value accompanying a function call, and parallelism is guaranteed.

The invention according to claim 7 is characterized in that the client monitoring means is realized by a thread.

According to the invention of claim 7, the function of the client monitoring means can be realized by one or a plurality of threads.

In the invention according to claim 8, the client monitoring means further comprises a function return waiting queue for temporarily storing the identifier of the thread in the function return value waiting state after calling the function, and the client process When the function return value is received, the received function return value is
It is characterized by transmitting to the thread of the identifier stored in the function return waiting queue.

According to the invention of claim 8, a plurality of threads inside a process can call a function to a single server and independently wait for the return of the function, and the function return value can be sent to the thread. It is possible to reliably perform transmission, and to realize parallel operation of threads more reliably and easily.

The invention according to claim 9 is characterized in that the server process and the client process further perform any of transmission, reception, and transmission / reception of a message relating to an event or a notification.

In the invention according to claim 9, the "message" is transmitted when an event or notification is performed between the server process and the client process, and does not require a return value like a function. Say something.

According to the ninth aspect of the present invention, the inter-process communication in the device can be performed by the message other than the function call, and the device having the functional diversity can be provided. Also, by implementing inter-process communication that does not require synchronization between threads by means of messages, it is possible to improve the processing speed of inter-process communication in the device.

Further, the invention according to claim 10 is characterized in that the client monitoring means further monitors reception of a message from the server process.

According to the tenth aspect of the present invention, the message sent from the server process can be collectively received by the client monitoring means, and the processing efficiency of inter-process communication in the device can be improved.

The invention according to claim 11 is characterized in that the client monitoring means further comprises a message handler for executing processing based on the received message.

According to the eleventh aspect of the present invention, the received message can be entrusted to the corresponding message handler, and the processing efficiency of interprocess communication using the message can be improved.

“Message handler” in the present invention
Is only required to deliver a received message to a thread, and a separate message handler is provided for each message, or a single module for delivering and receiving all receivable messages.

Further, the invention according to claim 12 is characterized in that the server process comprises a server monitoring means for monitoring a function call from the client process.

According to the twelfth aspect of the present invention, the function call from the client process can be collectively received by the server monitoring means, and the processing efficiency of inter-process communication in the device can be improved.

The invention according to claim 13 is characterized in that the server monitoring means monitors a function call from a plurality of client processes.

According to the thirteenth aspect of the present invention, the server process can operate as a server process for a plurality of client processes, and a plurality of applications and a plurality of control services can be used as client processes to perform various functions. Can be provided by the server process, and various functionally various devices can be provided.

The invention according to claim 14 is characterized in that, when the server monitoring means receives a function call from the client process, it has a function handler for executing a process corresponding to the called function. And

According to the fourteenth aspect of the present invention, the server process can provide the service to be provided to the client process through inter-process communication using the function handler, thereby providing a functionally diverse device. be able to.

Further, the processing corresponding to the function can be entrusted to the function handler, and the service can be provided to the client process if a function handler for executing the function provided as the server process is provided in advance. Therefore, even if a function to be provided is added or changed, it is not necessary to make a large change in the function of the server monitoring means simply by adding or changing the function handler, and thus it is possible to easily provide a device having variability. it can.

The "function handler" in the present invention only needs to execute the processing corresponding to the function called from the client process, and it simply executes all the functions provided by the server process as the function handler for each function. Besides one module, a separate function handler may be provided for each function. In this case, it is possible to further increase the variability of the device.

Further, the invention according to claim 15 is characterized in that the server monitoring means further monitors reception of a message from the client process.

According to the fifteenth aspect of the present invention, the message sent from the client process can be collectively received by the server monitoring means, and the processing efficiency of interprocess communication in the device can be improved.

Further, the invention according to claim 16 is characterized in that the server monitoring means further comprises a message handler for executing processing based on the received message.

According to the sixteenth aspect of the present invention, the processing related to the received message can be entrusted to the message handler, and the processing efficiency of interprocess communication using the message can be improved.

“Message handler” in the present invention
Also, as long as the received message is passed to the thread, a separate message handler may be provided for each message, or a single module that performs the process of passing all receivable messages may be used.

As a next aspect of the present invention, in the apparatus according to any one of the above inventions, the control service has an engine control service for controlling a job or an engine, and the engine control service is provided. Is provided with a function handler that executes job control processing or engine control processing when a function call is received from a client process.

According to the present invention, the engine control service is provided with the function handler for executing the job control process or the engine control process when the function call is received from the client process. Therefore, the job control service provided by the engine control service is provided. A service related to processing or engine control processing can be provided to a client process by interprocess communication using a function handler, and a device having various functions can be provided.

Further, even if the job control or engine control function provided by the engine control service as a server process is added or changed, a large change on the engine control service side is not necessary just by adding or changing the function handler. It is possible to easily provide a variable device.

As a next aspect of the present invention, in the apparatus described in the above invention, the engine control service further transmits a message regarding job control or engine control.

According to the present invention, the engine control service further sends a message related to job control or engine control, so that a message other than a function such as an event or notification related to job control or engine control that does not require a return value is messaged. Realized by
It is possible to provide a functionally diverse device.

Further, as a next aspect of the present invention, in the apparatus according to any one of the above inventions, the control service has a memory control service for controlling a memory or a hard disk device, and the memory The control service is provided with a function handler that executes memory control processing or hard disk control processing when it receives a function call from the client process.

According to the present invention, the memory control service is provided with the function handler for executing the memory control process or the hard disk control process when the function call is received from the client process. It is possible to provide a client process with a service related to a process or a hard disk control process by interprocess communication using a function handler, and it is possible to provide a device having various functions.

Even if the memory control service or the hard disk control function provided as a server process by the memory control service is added or changed, the function on the memory control service side can be greatly changed only by adding or changing the function handler. It is not necessary, and it is possible to easily provide a variable device.

As a next aspect of the present invention, in the apparatus described in the above invention, the memory control service further transmits a message regarding memory control or hard disk control.

According to the present invention, the memory control service further sends a message related to memory control or hard disk control, so that a message that does not require a return value such as an event or notification related to memory control or hard disk control other than a function is message It is possible to provide a device which is realized by the above and has various functions.

According to a seventeenth aspect of the present invention, the invention comprises a hardware resource corresponding to a process to be executed, and a process of a user service and a control service related to the process, and interprocess communication targeted for the process. A device having a function, wherein the control service operates as a server process for a client process of another device connected through a network, and provides one or a plurality of server processes as a server process to the client process of the other device. It is characterized by having a function that defines a service.

According to the seventeenth aspect of the present invention, the control service can realize inter-process communication using a function call as a server process with a process operating in another device on the network as a client, and the same. It is possible to provide services not only to processes in the device but also to devices on the network, and various functions can be realized.

In the invention according to the seventeenth aspect, the device on which the control service as the server process is operating is not limited in its configuration as long as the user service and the control service can be installed. That is, the device only needs to be equipped with at least one control service that provides a service, and includes a device without a user service and a device with only one control service.

Further, the invention according to claim 18 is characterized in that each process of the control service includes one or a plurality of threads for executing a service provided to a client process of the other device.

According to the eighteenth aspect of the present invention, it is possible to execute in parallel services provided to user service processes such as applications running on other devices on the network.

Therefore, for example, even when a function call is simultaneously received from a client process of a plurality of different devices on the network, the service is executed in parallel by a thread whose execution control is switched quickly. It is possible to quickly provide the service of.

Further, the invention according to claim 19 is characterized in that the control service comprises a server monitoring means for monitoring a function call from a client process of the other device.

According to the nineteenth aspect of the present invention, the function calls from the client processes of other devices are collectively received by the server monitoring means, and the processing efficiency of interprocess communication with the devices on the network is improved. Can be made.

The invention according to claim 20 is characterized in that the server monitoring means further monitors reception of a message from a client process of the other device.

According to the twentieth aspect of the invention, the control service can collectively receive the messages from the processes operating in the other devices connected to the network, and the inter-process communication with the devices on the network can be performed. The processing efficiency can be improved.

Further, the invention according to claim 21 is characterized in that the control service further transmits a message to a client process of the other device.

According to the twenty-first aspect of the present invention, the control service can perform inter-process communication using another message of a function as a server process with a process operating in another device connected to the network as a client. Therefore, various functions can be realized for the devices on the network.

Further, the invention according to claim 22 is characterized in that the control service operates as a server process in which a user service operating in the other device is a client process.

According to the twenty-second aspect of the present invention, the function of the control service can be provided to the process of the application operating on another device on the network.

Even if the control service does not exist in the device on the network or cannot be used, the function of the control service can be provided to the device on the network by the interprocess communication, so that a plurality of devices using the network can be provided. It becomes possible to share the functions of the control service between them.

The invention according to claim 23 is characterized in that the control service operates as a server process in which the control service operating in the other device is a client process.

According to the twenty-third aspect of the present invention, it is possible to provide the control service function to the control service operating in another device on the network.

Further, even when a certain control service does not exist in the device on the network or cannot be used, the function of the control service can be provided to the device on the network by interprocess communication.
It becomes possible to realize sharing of the control service function among a plurality of devices using the network.

The invention according to claim 24 is characterized in that the user service operates as a client process in which a control service operating on the other device is a server process.

According to the invention of claim 24, the user service can receive the service from the control service on the network. Even if the user service cannot be used on the devices on the network, the service can be provided from the control service of the devices on the network by interprocess communication. It becomes possible to realize sharing of control service functions.

The invention according to claim 25 is characterized in that the control service operates as a client process in which the control service operating in the other device is a server process.

According to the invention of claim 25, the control service can receive the service from the control service on the network. Even if the control service cannot be used on a device on the network, the service can be provided from the control service of the device on the network by interprocess communication. It becomes possible to realize sharing of the functions of.

[0095]

BEST MODE FOR CARRYING OUT THE INVENTION Preferred embodiments of an apparatus according to the present invention will be described in detail below with reference to the accompanying drawings. In the following embodiments, an image forming apparatus will be described as an example of an apparatus having an inter-process communication function according to the present invention, but any apparatus that performs inter-process communication as a server process or a client process by a plurality of processes may be used. Good. (Embodiment 1) FIG. 1 is a block diagram showing a configuration of an image forming apparatus (hereinafter referred to as a "multi-function peripheral") which is Embodiment 1 of the present invention. As shown in FIG. 1, the multifunction peripheral has hardware resources such as a black and white line printer (B & W LP) 101, a color line printer (Color LP) 102, a scanner 103, and a facsimile 104, and a platform 120. A software group 110 including an application 130 is provided.

The platform 120 interprets a processing request from the application 130 and generates a hardware resource acquisition request, and manages one or a plurality of hardware resources to arbitrate the acquisition request from the control service. It has a system resource manager (SRM) 123 and a general-purpose OS 121.

The control service is composed of a plurality of service modules, and includes an SCS (system control service) 122, an ECS (engine control service) 124, an MCS (memory control service) 125, and an OCS (operation panel control service) 126. And an FCS (fax control service) 127 and an NCS (network control service) 128. The platform 120 has an application program interface (API) capable of receiving a processing request from the application 130 by a predefined function.

The general-purpose OS 121 is UNIX (registered trademark)
Is a general-purpose operating system, and executes each software of the platform 120 and the application 130 as processes in parallel.

The SRM 123 controls the system and manages resources together with the SCS 122.
Engine of scanner and printer, memory, HD
D file, host I / O (Centro I / F, network I / F, IEEE 1394 I / F, RS232C
Arbitration is performed and execution control is performed according to a request from an upper layer that uses hardware resources (such as I / F).

Specifically, the SRM 123 determines whether the requested hardware resource is available (whether it is not used by another request), and if it is available, the requested hardware resource is available. Tell upper layers that resources are available. Further, the SRM 123 schedules the use of hardware resources in response to a request from the upper layer, and requests contents (for example, paper conveyance and image forming operation by the printer engine, memory reservation, file generation, etc.).
Are carried out directly.

The SCS 122 is for application management, operation unit control,
The system screen display, LED display, resource management, and interrupt application control are performed. The ECS 124 controls a hardware resource engine including a monochrome line printer (B & W LP) 101, a color line printer (Color LP) 102, a scanner 103, and a facsimile 104.

The MCS 125 acquires and releases an image memory, uses a hard disk device (HDD), and compresses and decompresses image data. OCS12
Reference numeral 6 is a module for controlling an operation panel which is a means for transmitting information between the operator and the main body control.

The FCS 127 is used for facsimile transmission / reception from each application layer of the system controller using the PSTN / ISDN network, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, fusion transmission / reception. It provides an API for performing. FCS12
7, the FCU handler 129 that is its subprocess
(FCUH) is started. This FCUH129 is F
The device driver of the facsimile engine is controlled during facsimile transmission / reception in accordance with a command from the CS 127.

The NCS 128 is a group of modules for providing services that can be commonly used for applications that require network I / O. The NCS 128 distributes the data received from each protocol from the network side to each application, and Is an intermediary for transmitting data from the network to the network side.

The application 130 is a page description language (PDL), PCL and Postscript (PS).
A printer application 111 having a printer application, a copy application 112 having a copy application, a fax application 113 having a facsimile application, a scanner application 114 having a scanner application, and a network file application having a network application. It has a file application 115 and a process inspection application 116 which is a process inspection application.

Each of these control services and SRM
123 and each application are general-purpose O as a process.
Generated on S and executed. Within each process, a plurality of threads are activated, and parallel execution is realized by switching the CPU occupation time of these threads under the control of a general-purpose OS. Each application process and each control service process perform transmission / reception of various messages and data and function call by inter-process communication described later.

FIG. 2 is a block diagram showing the relationship between the server process and the client process operating on the multi-function peripheral of the first embodiment. Here, the server process 202 is a process that provides a service to the client process 201 in response to a request from the client process 201. The client process 201 is a process that receives a service from the server process 202 by making a request to the server process 202.

In the multifunction machine of the first embodiment, the application processes such as the copy application 112, the printer application 111, the scanner application 114, the fax application 113, and the ECS 124, MCS 125, FC
The processes of the control service such as S127 and NCS128 are mainly the client process 201, and the processes of the control service and the SRM 123 are mainly the server process 202.

That is, when each application receives a service from the control service, the process of each application operates as the client process 201 and the control service operates as the server process 202. When requesting and providing a service between control services, the control service that requests the service operates as the client process 201, and the control service that provides the service operates as the server process 202.

Note that the application process, the control service process, and the SRM process are not limited to these examples, and can be the server process 202 and the client process 201. That is,
If these processes request service from any other process, the client process 201
On the other hand, when providing a service in response to a request from another process, it operates as the server process 202.

As shown in FIG. 2, the processes of these applications, control service, and SRM 123 are as follows.
In each case, multiple threads are running. Since each process has a plurality of threads, when a request from another process is received, the server process 202 that has the other process as the client process 201 is received.
At the same time, when a service is requested to another process, the other process operates as the client process 201 with the server process 202.

Further, each process can be a server process 202 in which a plurality of processes are client processes 201 at the same time. Furthermore, each process can be the client process 201 that receives services from a plurality of server processes 202 at the same time.

As shown in FIG. 2, the client process 2
In order to request the service of the server process 202, 01 performs a function call from the thread in the client process to the server process 202, and receives the function return value to perform inter-process communication.

Each thread of the client process 201 performs inter-process communication by sending a message to the server process 202. On the other hand, the inter-process communication from the server process 202 to the client process 201 is performed only by transmitting a message, and the function call cannot be performed.

Therefore, ECS 124, MCS 125, FCS 127, NCS which can be the server process 202.
In the control service such as 128 and the SRM 123, the service provided to the client process 201 is pre-installed as a function handler 403 described later for each service. When making a request for these services from the client process 201, it becomes possible to receive the service by calling a function for each service (by making a function call) to the server process 202. There is.

Here, the “message” is mainly transmitted when an event or notification is made between the server process 202 and the client process 201, and is a unique message ID, message name, message direction, message. It is data including contents.

In the message direction, "IN", "OU"
There are “T” and “SELF”, “IN” means a message transmitted from the client process 201 to the server process 202, and “OUT” means the server process 2.
Means a message transmitted from 02 to the client process 201. Further, "SELF" means a message to be sent to its own process.

The "function" is issued when the client process 201 makes a predetermined processing request to the server process 202 or makes a predetermined setting request. To return.

The thread of the client process 201 calls a function provided in advance by the server process 202. The server process 202 which has received the function call executes the process corresponding to the requested function and uses the execution result as the function return value to the client process 2
01 to the client dispatcher 203.
In addition, the function return value is a structure, and in addition to the return value, the function ID for identifying the function is included in the structure.

The client dispatcher 203 is a thread for monitoring the reception of OUT-direction messages or function return values from the server process 202. The client process 201 is one server process 202
One client dispatcher 203 is activated to communicate with the server process 202. When the client process 201 communicates with a plurality of server processes 202, one client dispatcher 203 is activated for each server process 202.

FIG. 3 is an explanatory diagram showing the detailed structure of the client dispatcher. The client dispatcher 203 uses the message handler 30 on that thread.
2, error handler 301 and default handler 3
Start 03.

The message handler 302 processes the received message.
There are multiple separate message handlers 302 for each D. Therefore, when the client dispatcher 203 receives a message, it determines the message ID included in the received message and calls the message handler 302 of the corresponding message ID. As the processing contents of the message handler 302, for example,
Although there are processes such as notifying the thread that made the function call of the message contents, different process contents are defined for each message.

The error handler 301 is called when an error occurs during execution of the client dispatcher 203, and performs error processing such as notifying the user of an error. The default handler 303 is the message I for which the corresponding message handler 302 is not registered.
It is called when the D message is received and performs processing such as notifying the thread of the message.

Also, the client dispatcher 203
Holds a function return wait queue 304, and manages the function return value and the thread 305 in the function return wait state by using this function return wait queue 304. That is, the thread of the client process 201 makes a function call to the server process 202, but after the function call, the thread returns to the function return waiting state until the function return value is received, and the subsequent processing is suspended.

When a function call is made from the thread 305, the client dispatcher 203 uses the identifier (thread ID etc.) of the thread 305 as the function I of the function.
It is registered in the function return waiting queue 304 together with D. When the client dispatcher 203 receives the function return value from the server process 202, the function ID
The key is used as a key to search the function return waiting queue 304, and the identifier (thread ID or the like) of the thread 305 whose processing is suspended is detected by waiting for reception of the received function return value. Then, the client dispatcher 203 transmits the received function return value to the thread having the detected identifier (thread ID). The thread that received the function return value exits the return wait state and can continue processing after the function call. The client dispatcher 203 notifies such a return value each time the function return value is received.

The server dispatcher 204 is a thread that monitors function calls and IN-direction messages from the threads of the client process 201. Unlike the client dispatcher 203, one server dispatcher 204 can receive function calls and messages from multiple client processes 201.

FIG. 4 is an explanatory diagram showing a detailed structure of the server dispatcher 204. Server dispatcher 20
4 starts the function handler 403, the message handler 402, the error handler 401, and the default handler 404 on the thread.

The function handler 403 executes specific processing of the function, and there are a plurality of functions for each function. The server dispatcher 204 uses the client process 2
When the function call is received from 01, the function handler 403 corresponding to the received function is activated, and the function handler 403
Executes the processing requested by the client process 201 and returns the function return value to the client process 201.
To the client dispatcher 203.

The message handler 402 is for processing the received message.
There is more than one for each D. Server dispatcher 204
When the message is received, the message ID included in the received message is determined, and the corresponding message ID
The message handler 402 is called. The processing content of the message handler 402 includes, for example, processing for notifying the thread of the content of the message, but different processing content is defined for each message.

The error handler 401 is called when an error occurs during execution of the server dispatcher 204, and performs error processing such as error notification. The default handler 404 is the corresponding message handler 402
Is called when a message with a message ID that is not registered is received, and performs processing such as notifying the message to the thread.

Next, the interprocess communication in the printer operation, the scanner operation, the copy operation and the facsimile transmission operation that are actually performed in the multifunction machine 100 of the first embodiment will be specifically described.

First, the printer application 111, ECS124, MCS125, SRM123 in the printer operation.
Interprocess communication of will be described. FIG. 5 is an explanatory diagram showing a data sequence between each process of the printer application, ECS, MCS, and SRM when the printer operation is performed by the multifunction peripheral of the first embodiment. FIG. 6 is an explanatory diagram showing the relationship between functions and message transmission / reception between processes.

As shown in FIG. 6, the multifunction peripheral 100 has a printer application process 111, an ECS process 124, and an MCS process.
The CS process 125 and SRM process 123 are running. These processes are generated when the multifunction peripheral 100 is started. It should be noted that FIG. 6 shows only the processes used in the printer operation, and in fact, other application processes and processes for other control services are also generated when the multifunction peripheral 100 is started.

The printer application process 111 is activated when the multifunction machine is activated, and a plurality of threads are activated in the process as shown in FIG. The printer application process 111 is a client process that uses the ECS process 124 as a server process.
A client dispatcher that receives a message or a function return value from the process 124 and notifies the thread in the process is started as a thread.

During printer operation, the ECS process 124 serves as a server process using the printer application process 111 as a client process, and also serves as a client process using the MCS process 125 and SRM process 123 as server processes. Therefore, in the ECS process 124, a thread of a server dispatcher that receives a function call and a message from the printer application process 111 and sends a message and a function return value to the printer application process 111, and the MCS process 125 or the SRM process 1
A client dispatcher that receives messages from 23 and function return values and manages the return values, and a plurality of threads that perform processing related to other job control and engine control are operating.

When the printer is operating, the MCS process 125 becomes a server process with the ECS process 124 as a client process, and the SRM process 1
It becomes a client process with 23 as a server process. Therefore, in the MCS process 125, a thread of a server dispatcher that receives a function call and a message from the ECS process 124 and sends a message and a function return value to the ECS process 124,
A client dispatcher that receives messages and function return values from the SRM process 123 and manages the return values, and a plurality of threads that perform processing related to memory control or hard disk control are operating.

When the printer is operating, the SRM process 123 uses the ECS process 124 or the MCS process 12
It is a server process with 5 as the client process. ECS process 1 in SRM process 123
24 or MCS process 125 to receive function calls and messages and ECS process 124 or MC
A thread of a server dispatcher that sends a message and a function return value to the S process 125, and other threads that perform various processes related to engine resource control are operating.

In the printer application process 111 according to the first embodiment, one thread is used to perform each function call of job operation mode setting and job start request. Further, in the ECS process 124, the process of repeatedly calling the memory image information request function for the number of printed sheets is one thread, and the process of performing the resource acquisition request function call is one thread. In the MCS process 125, the process of making a memory acquisition request function call is one thread. However, the processing in each of these threads is an example, and can be arbitrarily set in each program.

From a host such as a PC, a Centro I / F, U
When there is a print request 1 via the SB I / F, network I / F, etc., the NCS process receives the print request 1 and transfers it to the printer application process (step S50).
1). Upon receiving the print request from the NCS process, the printer application process 111 creates a new print job, and in thread 1 calls a job operation mode setting request function call to the ECS process 124 (step S502).

Thereafter, this thread 1 waits for reception of the function return value, and the identifier (thread ID) of the thread 1 is registered in the function return waiting queue by the client dispatcher. Here, the job operation mode is a group of parameters required to operate the scanner, plotter, finisher, etc., such as print paper size, number of copies,
It defines the operation conditions of a job generated from printer conditions such as a paper feed tray.

For the sake of simplification of description, the identifier (thread ID) of the thread that has made a function call to the server process and is in the function return waiting state will be stored in the function return waiting queue together with the function ID by the client dispatcher. The registration is simply expressed as "the thread is in a function return wait state".

In the ECS process 124, the server dispatcher receives the job operation mode setting function call from the printer application process and activates the job operation mode setting function handler on the thread of the server dispatcher. Then, the above-mentioned job operation mode is set for the printer job newly generated by the job operation mode setting function handler, and the function return value (for example, normal or error occurrence) is transmitted to the client dispatcher of the printer application process 111. .

The client dispatcher of the printer application process 111 receives the function return value of the job operation mode setting function from the ECS process 124, retrieves the thread 1 waiting for the function return value from the function return wait queue, and determines the job operation mode. The return value of the setting function is extracted and sent to thread 1.

For simplification of the description, the client dispatcher searches the function return waiting queue for the identifier (thread ID) of the thread in the function return waiting state, and finds the thread with the retrieved identifier (thread ID). Receiving the function return value from the client dispatcher is simply expressed as "the thread receives the function return value via the client dispatcher".

When the thread 1 receives the function return value of the job operation mode setting from the client dispatcher, it exits the return wait state and requests the start of the job. Therefore, the job start request function is called to the ECS process 124 (step S503). ), The function returns to the waiting state.

In the ECS process 124, the server dispatcher receives the job start request function call from the printer application process 111, activates the job start request function handler on the thread of the server dispatcher, and starts the job by the job start request function handler. The function return value is processed and sent to the client dispatcher of the printer application process 111.

The client dispatcher of the printer application process 111 receives the return value of the job start request function from the ECS process 124, and the thread 1 receives the return value of the job start request function via the client dispatcher.

Next, the ECS process 124 sends a memory image information request message to the MCS process 125 in the thread 3 in order to obtain the print data stored in the memory (step S504).

In the MCS process 125, the server dispatcher receives the memory image information request message from the ECS process 124 and activates the memory image information request message handler. Then, the image data stored in the memory is acquired by the memory image information request message handler, and the image data is transferred to the ECS process 1
24 (step S505).

The client dispatcher of the ECS process 124 receives the image data from the MCS process 125 and transfers it to the thread 3. The process of transmitting the memory image information request message and the process of receiving the image data are repeated until the print page is completed (steps S508 and S509).

On the other hand, in the MCS process 125, after transmitting the image data to the ECS process 124, the SRM process 12 is executed in the thread 5 to secure the image memory.
A memory acquisition request function call is made to step 3 (step S506), and a return waiting state is entered. SRM process 1
At 23, the server dispatcher has the MCS process 12
5, the memory acquisition request function call is received, the memory acquisition request function handler is activated, the image acquisition memory is reserved for printing by this memory acquisition request function handler, and the function return value is sent to the MCS process 125.

The client dispatcher of the MCS process 125 receives the return value of the memory acquisition request function from the SRM process 123, and the thread 5 receives the return value of this memory acquisition request function via the client dispatcher.

In the ECS process 124, after receiving the print data of the first page from the MCS process 125, the thread 4 makes a resource acquisition request function call to the SRM process 123 in order to acquire printer engine resources ( In step S507), the function returns to the waiting state. In the SRM process 123, the server dispatcher receives the resource acquisition request function call from the ECS process 124, activates the resource acquisition request function handler, occupies the printer engine by the resource acquisition request function handler, and returns the function return value to the ECS process 124. Send. E
The CS process 124 client dispatcher
The return value of the resource acquisition request function is received from the SRM process 123, and the thread 4 receives the return value of the resource acquisition request function via the client dispatcher.

In thread 3 of the ECS process 124,
When the response message of “no image” is received as the notification message for the memory image information request message (step S511) (step S512), it is determined that printing of all print pages is completed, and the printer application process 111 is notified. In response, a job end notification message is transmitted (step S513). In the printer application process 111, the client dispatcher receives this message, activates the message handler, and notifies the thread 1 of the job end notification message by the message handler.

Interprocess communication of printer operation is performed in this way. Here, as shown in FIG. 5, print request 1
A case will be described in which another print request 2 is transmitted from the NCS to the printer application process 111 during the print processing for the. (Step S521).

At this time, the printer application process 11
1, the ECS process 124, the MCS process 125, and the SRM process 123 perform inter-process communication similar to the above-mentioned function call (steps S522 and S5).
23, S524).

However, when the resource acquisition request function call is made from the thread 7 of the ECS process 124 to the SRM process 123 (step S527), the SRM is currently occupied by the print engine for the print request 1 because the printer engine is currently occupied by the print process. The process 123 does not immediately return the return value of the resource acquisition request function. Therefore, the thread 7 waits for a function return value for a while, and is registered in the function return waiting queue. And print request 1
When the printer engine is released from occupation by
The SRM process 123 returns E as the return value of the resource acquisition request function.
The process is returned to the CS process 124 (step S528), whereby the thread 7 of the ECS process 124 continues to process the print request 2.

Here, an example has been described in which the printer job for the print request 2 cannot acquire the printer engine. In addition, when the ECS process 124 makes a memory acquisition request function call to the SRM process 123, the print job for print request 1 has already caused a memory shortage, and the print job for print request 2 cannot acquire the memory. In this case, the thread that has executed the memory acquisition request function call waits in the function return waiting state until the printer operation of the print request 1 is completed, and the printer operation for the print request 2 is interrupted.

Next, in the scanner operation performed by the multifunction peripheral 100 of the first embodiment, the scanner applications 114, E
Inter-process communication of the CS 124, MCS 125, and SRM 123 will be specifically described. FIG. 7 shows the first embodiment.
Scanner application when performing scanner operation with the multifunction machine of
It is explanatory drawing which shows the data sequence between each process of ECS, MCS, and SRM. Further, FIG. 8 is an explanatory diagram showing a relationship between functions and message transmission / reception between processes.

As shown in FIG. 8, the multifunction peripheral 100 has a scanner application process 114, an ECS process 124, and an MCS process.
The CS process 125 and SRM process 123 are running. These processes are generated when the multifunction peripheral 100 is started. Note that FIG. 8 shows only the processes used in the scanner operation, and actually other application processes and other control service processes are also generated when the multifunction peripheral 100 is activated.

The scanner application process 114 is activated when the multifunction peripheral is activated, and a plurality of threads are activated in the process as shown in FIG. The scanner application process 114 is a client process that uses the ECS process 124 as a server process.
The client dispatcher thread for process 124 is up.

When the scanner is operating, the ECS process 124 serves as a server process with the scanner application process 114 as a client process, and also serves as a client process with the MCS process 125 and the SRM process 124 as server processes. For this reason, in the ECS process 124, a server dispatcher thread for the scanner application process 114, a client dispatcher thread for the MCS process 125, a client dispatcher thread for the SRM process 123, and a plurality of processes related to job control or engine control are performed. Thread is running.

The MCS process 125 is a server process in which the scanner application process 114 and the ECS process 124 are client processes during the scanner operation. Therefore, the scanner application process 114 and the ECS process 124 are included in the MCS process 125.
There are multiple threads running for the server dispatcher thread and other threads that perform processing related to memory control or hard disk control.

The SRM process 123 becomes a server process with the ECS process 124 as a client process. Therefore, in the SRM process 123, there are a thread of the server dispatcher for the ECS process 124 and a plurality of other threads for processing related to engine resource control. It's working.

In the scanner application process 114 according to the first embodiment, a series of processes for performing each function call of a job open request function, a job operation mode setting request, and a job start request during a scanner operation, and a process for performing a file generation request function call The processing for making the file information registration request function call and the file close request function call is each one thread.

In the scanner application process 114, a file open request function call, a work area reservation request function call and a page open request function call process, a read request function call process, and a page close process are performed when reading a scanned image. A thread performs a series of processing for request function call, page delete request function call, work area delete request function call, file close request function call, and file delete request function call.

In the ECS process 124, one thread includes a process for making a resource acquisition request function call, and a series of processes for repeatedly making a page generation request function call and a manuscript feed-in and page close request function call for the number of originals. However, the processing in each of these threads is an example, and can be arbitrarily set in each program.

When a scan request is issued to the scanner application process 114, the scanner application process 114
Create a new scanner job and E in thread 1
A job open request function call is made to the CS process 124 (step S701). After that, this thread 1 enters the function return waiting state, and is registered in the function return waiting queue together with the function ID of the function called by the identifier (thread ID) of the thread 1 by the client dispatcher.

Further, in the scanner application process 114, the MCS process 1 is executed by the thread 2 in parallel with this.
A file generation request function call is made to 25 (step S702). After that, this thread 2 waits for a function return, and similarly, the thread 2 identifier (thread ID)
Is registered in the function return wait queue.

In the ECS process 124, the server dispatcher receives the job open request function call from the scanner application process 114 and activates the job open request function handler on the thread of the server dispatcher. Then, the job is opened by the job open request function handler and the function return value is sent to the client dispatcher of the scanner application process 114.

On the other hand, in the MCS process 125, the server dispatcher receives the file generation request function call from the scanner application process 114, and the file generation request function handler generates a file for temporarily storing the scanned image on the hard disk. Then, the function return value is transmitted to the client dispatcher of the scanner application process 114.

The client dispatcher of the scanner application process 114 receives the function return value of the job open request function from the ECS process 124, and
The return value of the file creation request function is received from the MCS process 125, and the thread 1 in the job open request function return waiting state and the thread 2 in the file creation request function return waiting state are detected from the function return value queue, and the job open request function is detected. To the thread 1, and the return value of the file generation request function to the thread 2.

When the thread 1 receives the return value of the job open request function from the client dispatcher, it exits the return wait state and sets the job operation mode. Therefore, the thread 1 calls the job operation mode setting request function to the ECS process 124 (step S703), thread 1
Enters the function return wait state.

In the ECS process 124, the server dispatcher receives the job operation mode setting request function call from the scanner application process 114, sets the above-mentioned job operation mode in the scanner job by the job operation mode setting request function handler, and returns to the function. Send the value to the client dispatcher of the scanner app process 114.

The client dispatcher of the scanner application process 114 receives the return value of the job operation mode setting request function from the ECS process 124. The thread 1 receives the return value of the job operation mode setting request function via the client dispatcher and exits the function return waiting state.

In the thread 1 that has exited the function return waiting state, the job start request function call is issued to the ECS process 1
24 (step S704), the thread 1 enters the function return waiting state. In the ECS process 124,
The server dispatcher receives the job start request function call, the job start request function handler performs job start processing, and sends the function return value to the client dispatcher of the scanner application process 114. The client dispatcher of the scanner application process 114 receives the return value of the job start request function from the ECS process 124, and the thread 1 receives the function return value of the job start request function via the client dispatcher.

At this time, in the ECS process 124, the resource acquisition request function call is made to the SRM process 123 in the thread 3 due to the resource competition of the scanner engine (step S705), and the function return waiting state is entered. Further, in parallel with this, the ECS process 124 makes a page generation request function call to the MCS process 125 in the thread 4 in order to secure a memory for storing the scan image in page units (step S70).
6) The function returns to a waiting state. At this point, the identifiers of the threads 3 and 4 (thread IDs) are stored in the function return wait queue together with the function ID of the called function.

In the SRM process 123, the server dispatcher receives the resource acquisition request function call, and the resource acquisition request function handler occupies the scanner engine and sends the function return value to the ECS process 124. In the MCS process 125, the server dispatcher receives the page generation request function call, reserves the memory for one page by the page generation request function handler, opens the secured page, and sends the function return value to the ECS process 124. .

The client dispatcher of the ECS process 124 receives the return value of the resource acquisition request function from the SRM process 123 and the return value of the page generation request function from the MCS process 125. Then, the thread 3 in the function return waiting state receives the return value of the resource acquisition request function via the client dispatcher, and the thread 4 also receives the return value of the page generation request function via the client dispatcher.

The thread 4 exits the return waiting state by receiving the function return value, then transmits a document feed-in instruction message to the scanner engine (step S707), and causes the scanner to read the document. Let it start. When the document reading operation for one page is completed, the scan completion notification message is transmitted from the scanner engine to the ECS process 124 (step S708). Therefore, the thread 4 of the ECS process 124 receives the scan completion notification message and receives the MCS. A page close request function call is made to the process 125 (step S709), and the process waits for a return.

Upon receiving the page close request function call, the MCS process 125 closes the image memory for one page opened on the memory by the page close request function handler and returns the function return value to ECS.
Send to the client dispatcher of process 124.

The client dispatcher of the ECS process 124 receives the return value of the page close request function, and the thread 4 in the function return waiting state receives the return value of the page close request function via the client dispatcher. In the thread 4, the function return waiting state is thereby exited, and the processing from the page generation request function call to the page close request function call described above (step S706-).
S709) is repeated for the number of documents.

When the scanning of the last page of the document is completed, the scanner engine sends a scan processing completion notification message to the thread 4 (step S710).
The thread 4 sends this scan processing completion notification message to the scanner application process 114 (step S711), and also sends a job end notification message (step S712).

The client dispatcher of the scanner application process 114 sequentially receives the scan processing completion notification message and the job end notification message from the ECS process 124 and notifies the thread 1. On the other hand, the thread 5 of the scanner application process 114 makes a file information registration request function call to the MCS process 125 (step S713) and waits for a function return.

In the MCS process 125, when the server dispatcher receives the file information registration request function call, the file information registration request function handler causes the file in which the scanned images of all the originals temporarily stored are stored, File information such as file name and storage location is registered, and the function return value is sent to the client dispatcher of the scanner application process 114.

When the thread 5 of the scanner application process 114 receives the return value of the file information registration request function via the client dispatcher, the MCS process 1
A file close request function call is made to 25 (step S714), and a function return waiting state is entered. MC
In S process 125, the server dispatcher receives this file close request function call, the file close request function handler closes the scan image file, and returns the function return value to the scanner application process 1
Send to 14. The scanner application process 114 receives the return value of this file close request function, and the scan process ends.

Next, the scanner application process 114 performs the following processing in order to read the stored scan image. First, in the thread 6, the MCS process 125 sequentially performs a file open request function call for opening a scan image file, a work area reservation request function call for securing a work memory, and a page open request function call. (Step S715
~ S717). In the same manner as described above, the thread 6 enters the function return waiting state after making each function call, exits the return waiting state by notifying the function return value, and makes the next function call.

The server dispatcher of the MCS process 125 sequentially receives a file open request function call, a work area reservation request function call, and a page open request function call from the thread 6 of the scanner application process 114, and performs a scan image file open process, Each function handler performs a work memory reservation process and a page open process, and sends each function return value to the scanner application process 114. Scanner application process 1
At 14, the client dispatcher sequentially receives the return values of the file open request function, the work area securing request function, and the page open request function, and the thread 6 receives the function return value via the client dispatcher.

In the scanner application process 114, the thread 7 makes a read request function call to read image data from the scan image file (step S718), and the thread 7 enters the function return waiting state. Further, the thread 8 makes a page close request function call to the MCS process 125 (step S719), and the thread 8 enters the function return waiting state.

The MCS process 125 receives a read request function call from the thread 7 of the scanner application process 114 after the page open processing requested by the thread 6 is completed, and the read request function handler receives the image data from the scanner image file. The function return value is read out and transmitted with the image data to the scanner application process 114. In the scanner application process 114, the thread 7 receives the return value of the read request function via the client dispatcher, exits the function return wait state, makes the next read request function call, and similarly receives the function return value.

In the MCS process 125, when the last read request processing which is the request from the thread 7 is completed,
Start the function handler of the page close request function received from thread 8 of the scanner application process 114,
Close the open page data,
The function return value is sent to the scanner application process 114. In the scanner application process 114, the thread 8 receives the return value of the page close request function via the client dispatcher, and exits the function return wait state. As a result, the thread 8 sequentially executes a page delete request function call, a work area delete request function call, a file close request function call, and a file delete request function call (steps S720 to S723).

The MCS process 125 receives these function calls in order, and deletes the page data, the working memory, the scan image file, and the scan image file by the function handler corresponding to the received function call. Each processing of deletion is performed, and each function return value is transmitted to the scanner application process 114.

In the thread 8 of the scanner application process 114, each function return value from the MCS process 125 is received via the client dispatcher,
The scan image reading process is completed.

Next, in the copy operation performed by the multi-function peripheral 100 according to the first embodiment, the copy application 112, the ECS
Inter-process communication of 124, MCS 125, and SRM 123 will be specifically described. FIG. 9 shows a copy application, ECS, and
It is explanatory drawing which shows the data sequence between each process of MCS and SRM. Further, FIG. 10 is an explanatory diagram showing the relationship between functions and message transmission / reception between processes.

As shown in FIG. 10, the copy machine process 112, ECS process 124, M
The CS process 125 and SRM process 123 are running. These processes are generated when the multifunction peripheral 100 is started. Note that FIG. 10 shows only the processes used in the copy operation, and actually other application processes and other control service processes are also generated when the multifunction peripheral is started.

The copy application process 112 is executed by the multifunction device 1
00 is started, and a plurality of threads are started in the process as shown in FIG. The copy application process 112 is a client process that uses the ECS process 124 as a server process.
The client dispatcher thread for the CS process 124 is up.

During the copy operation, the ECS process 124 serves as a server process using the copy application process 112 as a client process, and also serves as a client process using the MCS process 125 and SRM process 123 as server processes. Therefore, in the ECS process 124, the thread of the server dispatcher for the copy application process 112 and M
A thread of the client dispatcher for the CS process 125, a thread of the client dispatcher for the SRM process 123, and a plurality of other threads that perform processing related to job control and engine control are operating.

During the copy operation, the MCS process 125 becomes a server process with the ECS process 124 as a client process, and the SRM process 12
It becomes a client process with 3 as a server process. Therefore, in the MCS process 125, a thread of the server dispatcher for the ECS process 124, a thread of the client dispatcher for the SRM process 123, and a plurality of threads for performing various processes related to memory control and hard disk control are operating.

The SRM process 123 becomes a server process with the ECS process 124 and the MCS process 125 as client processes. Therefore, the SRM process 123 contains the ECS process 124 and MCS.
A thread of the server dispatcher for the process 125 and a plurality of threads that perform processing related to resource control of the engine are operating.

In the copy application process 112 according to the first embodiment, a series of processes for performing a job open request function call, a job operation mode setting function call and a job start request function call at the time of copying, and a process for performing a job close request function call are performed. Each has one thread.

In the ECS process 124, one thread is used for the memory reservation request function call, one is for the resource acquisition request function call, and the other is the manuscript feed-in processing. In the MCS process 125, the process of making a memory acquisition request function call is one thread. In addition,
Even in the copy operation, the processing in each thread is an example, and can be arbitrarily set in each program.

When there is a copy request, the copy application process 112 creates a new copy job, and the thread 1
In step S901, a job open request function call is made to the ECS process 124 (step S901). As a result, the thread 1 waits for a function return, and the function I of the job open request function called by the identifier (thread ID) of the thread 1 by the client dispatcher.
It is registered in the function return waiting queue together with D.

In the ECS process 124, the server dispatcher receives the job open request function call from the copy application process 112 and activates the job open request function handler on the thread of the server dispatcher. Then, the copy job is opened by the job open request function handler, and the function return value is transmitted to the client dispatcher of the copy application process 112.

The client dispatcher of the copy application process 112 receives the return value of the job open request function from the ECS process 124, and searches the function return value waiting queue for a thread in the function return waiting state. Then, the return value of the job open request function is transmitted to the retrieved thread 1.

When thread 1 receives the return value of the job open request function from the client dispatcher,
To exit the return wait state and set the job operation mode, a job operation mode setting function call is made to the ECS process 124 (step S902), and the function return wait state is entered.

On the other hand, the thread 2 makes a job start request function call to the ECS process 124 (step S903) and enters a function return waiting state. At this point, the identifier of thread 1 (thread ID) is registered in the function return waiting queue together with the function ID of the job operation mode setting function, and the identifier of thread 2 (thread I) is registered.
D) is registered by the client dispatcher with the function ID of the job start request function.

In the ECS process 124, the server dispatcher receives the job operation mode setting function call from the copy application process 112, sets the above-mentioned job operation mode in the copy job by the job operation mode setting function handler, and returns the function return value. Send to the client dispatcher of the copy application process 112. Further, the server dispatcher receives the job start request function call, performs job start processing by the job start request function handler, and sends the function return value to the client dispatcher of the copy application process 112.

The client dispatcher of the copy application process 112 receives the return values of the job operation mode setting function and the job start request function from the ECS process 124, and the thread 1 receives the return values of the job operation mode setting function via the client dispatcher. The thread 2 also receives the return value of the job start request function via the client dispatcher.

When the ECS process 124 sends the return value of the job start request function to the copy application process 112, it is necessary for the MCS process 125 in the thread 3 to secure the memory for storing the scanned image. A memory reservation request function call specifying the size is performed (step S904), and a function return waiting state is entered. In parallel with this, in thread 4,
In order to acquire the resources of the scanner engine and the printer engine, a resource acquisition request function call is made to the SRM process 123 (step S906), and the function return waiting state is entered.

In the MCS process 125, when the server dispatcher receives the memory reservation request function call, it reserves the memory area of the size specified by the memory reservation request function handler and sends the function return value to the ECS process 124. On the other hand, in the SRM process 123,
The server dispatcher receives the resource acquisition request function call, the resource acquisition request function handler occupies the scanner engine and the printer engine, and returns the function return value to the ECS.
Send to process 124.

The client dispatcher of the ECS process 124 receives the return value of the memory allocation request function from the MCS process 125 and, at the same time, receives the SRM process 1
23, the return value of the resource acquisition request function is received. Then, the thread 3 receives the return value of the memory allocation request function via the client dispatcher, and the thread 4 also receives the return value of the resource acquisition request function via the client dispatcher. As a result, the threads 3 and 4 exit the function return wait state.

When the return value of the resource acquisition request function is received and the scanner engine and the printer engine are occupied by the copy job, the ECS process 124 performs the document feed-in to the scanner engine in the thread 5 (step S907). This starts the document scanning process of the copy operation.

When the scanner engine completes the document scanning process, it sends a scan end notification message to the thread 5 of the ECS process 124 (step S90).
8) The printer engine starts print processing of the scanned image. Then, when the print processing of the scanned image ends in the printer engine, the print end notification message is transmitted to the thread 5 of the ECS process 124 (step S910).

In the ECS process 124, when the thread 5 receives the scan end notification message from the scanner engine, it sends the scan end notification message to the copy application process 112 (step S909). When the thread 5 receives the print end notification message from the printer engine, the thread 5 sends a job end notification message indicating the end of printing to the copy application process 112 (step S911).

In the copy application process 112, the client dispatcher receives two job end notification messages and activates the message handler to notify thread 2 of each job end notification message. As a result, the copy operation for one page of the document is completed.

When a plurality of originals are to be copied, a job start request function call is further made to the ECS process 124 (step S912), and the same operations as above are performed by the ECS process 124, MCS process 125, and
This is performed by the SRM process 123, the scanner engine, and the printer engine (steps S913 to S91).
6). When the copy application process 112 receives the final job end notification message (step S917) after copying all the originals, the thread 1 makes a job close request function call to the ECS process 124 (step S918).

In the ECS process 124, the server dispatcher receives this job close request function call, the job close request function handler closes the copy job in the open state, and sends the function return value to the copy application process 112.

In the copy application process 112, the client dispatcher receives the return value of the job close request function, and the thread 2 in the return waiting state receives the return value of the job close request function via the client dispatcher and copies it. The operation is completed.

When the scanner application process 114 receives a scan request during the above-described copy operation, the following processing is performed. For example, in a copy operation, ECS process 124 to SRM process 1
Consider a case in which the scanner application process 114 receives a scan request after the scanner engine and printer engine resource acquisition request function calls have been made to 23.

In this case, in the above-described scanner operation in FIG. 7, the ECS process 124 calls the resource acquisition request function function of the scanner engine to the SRM process 123, but since the scanner engine is occupied by the copy job, the scanner engine is occupied. Cannot be earned in a job.

Therefore, in the scanner job, the return value of the resource acquisition request function is sent to the ECS process 124.
Do this after the copy job is complete and the scanner engine is released. During this time, the thread that has executed the resource acquisition request function call in the scanner job is in a function return waiting state and is waiting, and the scanner operation is suspended until the copy operation is completed. Also, during the copy operation, if the printer application process 111 receives a print request after the printer engine is occupied by the copy job, the print operation is similarly suspended until the copy operation is completed.

The scanner operation during the copy operation has been described by taking the case where the scanner job cannot be acquired by the scanner job. In addition, the ECS process 124 to the MCS process 1 in the scanner job.
On the other hand, when the page generation request function call is made, the thread that made the page generation request function call returns the function even if the page cannot be generated due to insufficient memory in the copy job. The scanner operation is suspended until the copy operation is completed.

Next, in the facsimile transmission operation performed by the multifunction machine of the first embodiment, the fax application 11
3, FCS127, ECS124, MCS125, SR
The inter-process communication of M123 will be specifically described.
FIG. 11 shows a fax application, FCS, ECS, MCS, SR for performing a copy operation in the multifunction machine of the first embodiment.
It is explanatory drawing which shows the data sequence between each process of M. Further, FIG. 12 is an explanatory diagram showing the relationship between functions and message transmission / reception between processes.

As shown in FIG. 12, the multifunction peripheral 100 includes a fax application process 113 and an FCS process 12.
7, FCUH process 129, ECS process 124,
The MCS process 125 and SRM process 123 are running. These processes are generated when the multifunction peripheral 100 is started. Note that FIG. 12 shows only the processes used in the fax transmission operation, and in fact, other application processes and other control service processes are also generated when the multifunction peripheral is activated.

The fax application process 113 is activated when the multifunction peripheral 100 is activated, and a plurality of threads are activated in the process as shown in FIG. The fax application process 113 is a client process in which the FCS process 127 is a server process, and therefore the thread of the client dispatcher for the FCS process 127 is activated.

During the facsimile transmission operation, the FCS process 127 serves as a server process with the fax application process 113 as a client process, and the ECS process 124 and FCUH process 12
It becomes a client process with 9 as a server process. Therefore, in the FCS process 127, the server dispatcher thread for the fax application process 113, the client dispatcher thread for the ECS process 124, and the FCUS process 12
Client dispatcher thread for 9 and
In addition, a plurality of threads that perform processing related to facsimile communication control are operating.

The FCUH process 129 is a sub process of the FCS process 127, and is a server process in which the SRM process 123 and the FCS 127 are client processes during a facsimile transmission operation. Therefore, in the FCUH process 129, the SRM process 12
3 and the server dispatcher thread for the FCS 127, and a plurality of threads for performing processing such as commands to the facsimile device driver.

During the facsimile transmission operation, the ECS process 124 serves as a server process using the FCS process 127 as a client process, and also serves as a client process using the MCS process 125 and the SRM process 123 as server processes. Therefore, the FCS process 12 is included in the ECS process 124.
Server dispatcher thread for 7 and MCS
A thread of the client dispatcher for the process 125, a thread of the client dispatcher for the SRM process 123, and a plurality of other threads that perform processing related to job control and engine control are operating.

During the facsimile transmission operation, the MCS process 125 serves as a server process using the ECS process 124 as a client process and also serves as a client process using the SRM process 123 as a server process. Therefore, in the MCS process 125, E
A thread of the server dispatcher for the CS process 124, a thread of the client dispatcher for the SRM process 123, and a plurality of other threads that perform processing related to memory control and hard disk control are operating.

The SRM process 123 serves as a server process using the ECS process 124 and the MCS process 125 as client processes, and also serves as a client process using the FCUH process 129 as a server process. Therefore, in the SRM process 123, E
A thread of a server dispatcher for the CS process 124 and the MCS process 125, a client dispatcher using the FCUH process 129 as a server process, and a plurality of other threads that perform processing related to engine resource control are operating.

Fax application 1 in the first embodiment
In 13, the processing for making a transmission start request function call and the processing for making a transmission mode change request are each one thread. In the FSC process 127, a series of processes for performing a job operation mode setting function call and a job start request function call during a fax transmission operation, a process for receiving a scan parameter request message and transmitting a scan parameter, EOM (there is a next page), The processing of notifying the next page information message such as EOF (no next page) is set as one thread.

The ECS process 124 has one thread for each of a series of processes for executing a memory reservation request function call and a resource acquisition request function call, and a process for transmitting a scan / feed-in process generation instruction message. M
In the CS process 125, the process of calling the memory reservation request function and the process of transmitting other messages are one thread.

In the SRM process 123, a series of processes for transmitting a feed start message, a feed-in end message, and a stamp execution instruction message, and a scan / feed-in process execution process are provided as one thread. In FCUH129, the processing for transmitting the next page information message such as EOM and EOF is one thread. It should be noted that even in the facsimile transmission operation, the processing in each of these threads is an example, and can be arbitrarily set in each program.

When there is a facsimile transmission request, the fax application process 113 creates a new facsimile transmission job and makes a transmission start request function call from thread 1 to the FCS process 127 (step S
1101), the thread 1 enters the function return waiting state. F
In the CS process 127, the server dispatcher receives the transmission start request function call from the fax application process 113, activates the transmission start request function handler, and the thread 3 of the transmission start request function handler causes the MCS process 125 to execute the job operation mode. A setting request function call is made (step S1102), and the thread 3 enters a function return waiting state.

In the ECS process 124, the server dispatcher receives the job operation mode setting request function call from the FCS process 127, sets the above operation mode in the facsimile transmission job by the job operation mode setting request function handler, and returns the function. To the client dispatcher of FCS process 127.

The client dispatcher of the FCS process 127 receives the return value of the job operation mode setting request function from the ECS process 124, and the thread 3 receives this return value via the client dispatcher.
As a result, the thread 3 exits the function return waiting state, then makes a job start request function call to the ECS process 124 (step S1103), and the thread 3 enters the function return waiting state.

Upon receiving the job start request function call, the MCS process 125 calls the memory reservation request function call to the MCS 125 by the job start request function handler (step S1104) and makes the resource acquisition request function call to the SRM process 123. Perform (step S1106). MC that received these function calls
The processing of the S process 125 and the SRM process 123 and the processing associated with the reception of the return value of each function in the ECS process 124 are the same as the processing during the copy operation, and thus the description thereof is omitted.

In the ECS process 124, when the return value of the resource acquisition function of the scanner engine is received, the thread 7
In step S110, a scanner parameter confirmation request message is transmitted to the FCS process 127.
7). Here, the scanner parameters are, for example, scan density such as fine and normal, document size, and the like. Upon receiving this scanner parameter confirmation request message, the FCS process 127 transmits the scanner parameter as a message to the ECS process 124 in the thread 4 (step S1108).

In the ECS process 124, the server dispatcher receives the scanner parameter message,
The thread 7 that has transmitted the scan parameter confirmation request message is notified, and the thread 7 transmits a scan / feed-in process generation instruction message to the SRM process 123 (step S1109). Upon receiving the scan / feed-in process generation instruction message, the SRM process 123 causes the thread 11 to generate and execute the scan / feed-in process (step S1110).

Then, a document feed-in start message is transmitted to the FCUH process 129 (step S1111). The FCUH process 129 receives the feed-in start message to start the document feed-in, which starts scanning the document and transmitting it to the designated destination.

When the scanning of the original is started, a next page original presence / absence notification message indicating whether or not there is an original of the next page is transmitted from the scanner engine to the ECS process. In the example of FIG. 11, the next page document existence notification message is notified (step S1112). When the scanning of the document is completed, the scanner engine sends a scan completion message to the ECS process 124 (step S1113).

The ECS process 124 sends the received scan end message to the FCS with the fact that the next page original is present.
It is transmitted to the process 127 (step S1114). On the other hand, when the document scanning ends, the SRM process 123
Instructs the FCUH process 129 to end the feed-in (step S1115), whereby the document feed-in ends.

Here, the fax application process 113
Makes a transmission mode change request function call to the FCS process 127 (step S1105), E
The CS process 124 sends a scan parameter confirmation request message to the FCS process 127 in the thread 6, while the FCS process 127 sends a scan parameter message to the ECS process 124 as described above (step S1118). ECS
In the process 124, when the scan parameter message is received, the SRM process 123 is instructed to execute the scan feed-in process of the next page, and the execution is started (steps S1119 and S1120).

On the other hand, when the facsimile transmission to the designated destination of one page is completed, the FCS process 127 transmits the EOM message (there is the next page in a different transmission mode) in the thread 5 to the FCUH process 129 (step S1121). Received FCUH process 1
29 transmits the EOM to the designated destination by the thread 13 (step S1122).

When the FCUH process 129 receives the notification of the normal reception from the designated destination (step S112)
3), the transmission success message is transmitted to the SRM process 123 (step S1124), and the message S is received.
The RM process 123 sends a process normal termination message to the ECS process 124 (step S11).
25). Further, the ECS process 124 that has received this transmits a scan processing completion notification message for the first page to the FCS process 127 (step S112).
6). Then, the SRM process 123, which has received the transmission success message, instructs the scanner engine to transmit the stamps such as the transmission date and time and the transmission source to the designated destination according to the instruction (step S1127).

Since the SRM process 123 starts the feed-in of the second page of the document, the FCUH process 1
A document feed-in start message is transmitted to 29 (step S1128). FCUH process 1
29 receives the feed-in start message and starts the document feed-in, whereby the scanning of the second page of the document and the transmission to the designated destination are started.

When the document scanning is started, the next page document presence / absence notification message is sent from the scanner engine to ECS.
11 is sent to the process, and in the example of FIG.
24 threads 9 have been notified (step S112).
9). When the scanning of the document is completed, the scanner engine sends a scan completion message to the ECS process 124 (step S1130).

The thread 9 of the ECS process 124 sends the received scan end message to the FCS process 127 together with the fact that there is no original on the next page (step S1).
131). On the other hand, when the scan ends, the thread 13 in the SRM process 123 instructs the FCUH process 129 to end the feed-in (step S113).
2) Then, the document feed-in ends.

When the facsimile transmission to the designated destination of page 2 is completed, in the FCS process 127, the thread 5
Sends an EOF message (no next page) to the FCUH process 129 (step S1124), and the FCUH process 129 that has received this message uses the thread 13 to send EO.
Send F to the specified destination.

When the FCUH process 129 receives the notification of normal reception from the designated destination (step S113)
5) The thread 13 transmits a transmission success message to the SRM process 123 (step S113).
6) Upon receiving this, the SRM process 123 sends a process normal termination message to the ECS process 124 by the thread 12 (step S1137).

Further, the ECS process 12 which has received this
4 is 2 for FCS process 127 by thread 9.
A scan processing completion notification message for the page is transmitted (step S1138). In addition, the SRM process 123 that has received the transmission success message instructs the thread 12 to transmit to the designated destination of the stamp such as the transmission date and time and the transmission source (step S1139).

The ECS process 124 then uses the FCS
A job end notification message is transmitted to the process 127 (step S1140), and the FCS process 127
By receiving this job end notification message at the client dispatcher, the fax transmission operation of all the originals is completed.

As described above, in the multifunction machine of the first embodiment,
Client processes such as each application process
Inter-process communication can be realized by requesting a service by a function call and transmitting / receiving a message to a process that serves as a server such as an ECS process, an MCS process, and an SRM process. Therefore, in the multifunction machine having the special configuration of the application 130 and the platform 120, it is possible to realize various functions of the complex service.

Further, in the multi-function peripheral of the first embodiment, the client dispatcher monitors and receives the function return value as a result of the service request by the function call, so that the synchronization control between the threads in the process is easily performed. be able to. Therefore, even if only some modules of the application process and multiple control services are changed, it is not necessary to change the interface with other processes if the function call and the return value of the function are designed properly. Therefore, it is possible to easily deal with a function change for each application and each control service, and it is possible to provide the multifunction device with variability.

Further, in the multi-function peripheral of the first embodiment, the threads can be executed in parallel, and at the same time, the thread-affinity function call and the function return value are controlled to perform the synchronization control between the threads in the inter-process communication. Therefore, the overhead at the time of switching the parallel processing can be minimized and the processing speed at the time of providing the composite service can be improved. (Second Embodiment) In the multifunction peripheral 100 according to the first embodiment, the relationship between the server process and the client process has been conceptually described. Therefore, in the second embodiment, the server process and the client process will be described more specifically. The multifunction peripheral 100 according to the second embodiment
The configuration is the same as that of FIG.

FIG. 13 is a block diagram showing in detail the relationship between the server process and the client process operating on the multifunction peripheral 100 of the second embodiment. Here, the client process 1600 is the server process 1610, 16
Server process 1 by making a request to 20
Receive service from 610, 1620, for example, S
A process such as CS122. Also, the server processes 1610 and 1620 are the client processes 160.
A process such as ECS 124 that provides a service to the client process 1600 in response to a request from 0.

As shown in FIG. 13, a plurality of threads 1601 are activated in the client process 1600. Since the client process 1600 has a plurality of threads 1601, it has a plurality of server processes 16.
Services can be requested to 10,1620 at the same time.

Further, the client process 1600 is
From the thread 1601 to the server process 161 to request the services of the server processes 1610 and 1620.
The inter-process communication is performed by making a function call to 0, 1620 and receiving the function return value.

The thread 1601 of the client process 1600 is the server process 1610, 16 beforehand.
Call the function provided by 20. The function is defined in the client stub 1602. The client dispatcher 1603 is a thread that monitors the reception of the function return value.

The client process 1600 activates the client dispatcher 1603 for each of the server processes 1610, 1620 to start the server process 1610,
1620. Then, the server processes 1610 and 1620 that have received the function call execute the processing corresponding to the requested function as follows.

For example, the server dispatcher 1611 of the server process 1610 uses the threads 1613 coded in the server skeleton 1612,
Select the thread 1613 corresponding to the requested function. The thread 1613 selected here corresponds to the function handler 403 described in the first embodiment. The thread 1613 of the server process 1610 executes the requested process and sends the execution result to the client process 1600 as a function return value.

Next, the client process 1600 according to the second embodiment and the server processes 1610 and 162.
A generation method for generating 0 and will be described. Figure 14
7 is a block diagram showing a functional configuration of an image forming apparatus communication program generating apparatus (hereinafter, referred to as “stub generator”) that generates a client process and a server process according to the second embodiment. FIG. The stub generator automatically generates a header, a client stub, and a server skeleton from a message file.

As shown in FIG. 14, the stub generator has an input unit 17 for inputting a message file 1701.
02, the syntax analysis unit 1703 that checks the syntax of the content described in the message file 1701, and the header 1706, the client stub 1707, and the server skeleton 17 from the description content of the message file 1701.
And a code generation unit 1704 for generating a code and storing them in a storage medium such as a hard disk.

First, the message file 1701 input to the stub generator, the header 1706 generated by the stub generator, and the client stub 1707.
The server skeleton 1705 will be described.

The message file 1701 is a source file in which the communication content of interprocess communication is described in a source code such as C language. FIG. 15 is an explanatory diagram showing a description example of a message file. As shown in FIG.
The message file 1701 includes another message file, an include declaration that declares an include header in C language description, a message description that describes a message transmitted and received between the server process and the client process, and a client process from the server process to the server process. The declaration of the function to be issued by is written.

The message is issued mainly when an event or notification is performed between the server process and the client process, and the message description of the message file 1701 includes a message name, a message ID, a message direction, and a message. It is designed to describe the contents.

In the message direction, "IN", "OU"
"T" and "SELF". "IN" means a message sent from the client process to the server process. “OUT” means a message sent from the server process to the client process. Also, "SELF" means a message to be sent to its own process.

The function is issued when a processing request or a setting request is made from the client process to the server process. In the function declaration of the message file 1701,
Only the function name, function type, and arguments are described, and the processing contents of the function are not described.

The client stub 1707 is a source file in which issuance of a function called from a client program to a server process is described. By compiling the client stub 1707 into a library and linking it with the client program,
The function call from the client program is issued to the server process via the client stub 1707.

FIG. 16 is an explanatory diagram showing an example of the client stub 1707 generated by the stub generator. As shown in FIG. 16, the client stub 170
7, a function call is made by calling a function handler registered in the server skeleton 1705 described later. Server skeleton 1705
Is a source file in which the function handler called from the client stub 1707 and the message handler are registered.

FIG. 17 is an explanatory diagram showing an example of the server skeleton 1705 generated by the stub generator. As shown in FIG. 17, the server skeleton 1705
A function handler corresponding to the function described in the client stub 1707 is registered in.

In the function handler, only the argument passing part is described, and the implementation description part that describes the processing content is generated in a blank state. In this implementation description part, the processing contents of the function issued from the client program via the client stub 1707 can be freely described by the developer of the server program. Header 1706
Is a server skeleton 1705 and a client stub 1
707 is a source file in which common definitions, declarations, etc. are described.

FIG. 18 is an explanatory diagram showing an example of the header 1706 generated by the stub generator. FIG.
As shown in, the header 1706 is generated in a state in which the include declaration described in the message file 1701, the message ID, the message declaration such as the message structure, the function declaration, and the function handler declaration are described. Has become.

Next, a process of generating the server skeleton 1705, the client stub 1707 and the header 1706 by the stub generator will be described. FIG. 19
FIG. 9 is a flowchart of a server skeleton, client stub, and header generation process.

Syntax analysis unit 1703 of stub generator
Checks the function declaration, message definition, include declaration, and C language description described in the message file 1701 (step S1801), and further, the function name defined in the message file 1701 and the message ID in the message definition. , The uniqueness of the message name is determined (step S1802).

If there is a syntax error in the description of the function declaration, the message definition, or the include declaration, or if any of the function name, message ID, and message name is duplicated, it is a syntax error for the user. A message to that effect is notified and the processing is terminated (step S180).
3, S1804).

After the syntax analysis, the code generator 1704 determines the header 17 from the description content of the message file 1701.
06, a server skeleton 1705, and a client stub 1707 are generated. Specifically, the include declaration and the C language description of the message file 1701 are transferred to the header 1706 as they are, and the message file 17
The message structure described in the 01 message definition is copied to the header 1706 (step S180).
5).

Further, the code generator 1704 automatically generates a function handler name from the function declaration of the message file 1701 (for example, in the case of the function name abc, the function handler name is generated as abc_handler), and the generated function handler name Is registered in the server skeleton 1705.

Then, in the processing of the function handler, the argument passing is described and the issuing of the return value area generation system call is described. The field of the implementation description section that describes the actual processing contents of the function handler is left blank, and after the implementation description section, the issuance of each system call for return value transmission and return value area release is described (step S1806).

The code generator 1704 also registers the function name and argument description in the client stub 1707 for each function declaration described in the message file 1701, and the function call message generation call is made in the processing of the function. Describe each system call for calling a function handler and releasing a return value (step S1807). A function return value wait system call that waits for a return value of the issued function is internally issued to the function handler call.

As described above, the client stub 1707 and the server skeleton 1705 are generated by the stub generator.
After the header 1706 is generated, the server object and the client object are completed.

The developer of the server program, the implementation description part of the function handler of the server skeleton 1705 (blank)
Describes the processing contents to be performed by the function handler using an editor, etc., and puts the server skeleton 1705 in the header 1
Compile with 706 to generate a server stub object. Also, while declaring the function handler registered in the server skeleton 1705, a message handler that sends and receives the message described in the message file 1701 to and from the client process, an error handler that performs error processing, a server initialization, a server dispatcher. Create a server source file that describes issuing system calls such as startup, compile it, and link it with the server stub object to complete the server program.

On the other hand, the client stub 1707 is compiled with the header 1706 to generate a client stub object. A client stub object is created for each server process, and the created multiple client stub objects are used as a library.

In addition, function issuance, function handler declaration,
A client that describes the declaration of an error handler that handles error processing, the message handler that sends and receives the message described in the message file 1701 to and from the client process, and the initialization of the client process and the issuing of system calls such as client dispatcher activation. Complete the client program by creating and compiling the program and linking with the stub library.

FIG. 20 is an explanatory diagram showing a sequence of calling and responding to the server program when a function call is made from the client program. It should be noted that the server program and the client program are actually executable object files.
In 0, the source code is displayed for convenience of explanation.

When an Open function is called from the client program to the server program,
Open defined in the client stub object
Is called (step S1901). Then, in the Open processing of this stub, the Open function handler Open_handler is called to the server program (step S1902).

In the server program, the function handler Open_handl is changed from the client stub object.
er is received, the process described in the implementation description part of the Open_handler registered in the server stub object is executed (step S190).
3) The execution result is returned to the client stub as a return value (step S1904). The client program receives this return value from the client stub (step S1905) and moves to the next process.

As described above, the stub generator according to the second embodiment can easily generate the client stub 1707 and the server skeleton 1705 by describing the function declaration in the message file 1701. Moreover, since the implementation description part of the generated server skeleton 1705 is blank, the program developer can easily change the processing contents of the function as needed.

For this reason, the multifunction peripheral 100 can be provided with variability and various functions can be realized. Furthermore, even when a third-party vendor or other company develops a client program, interprocess communication can be performed simply by describing the function call provided to the client program, so the internal communication protocol must be kept hidden. Is possible.

Further, in the stub generator of the second embodiment, since interprocess communication is realized by function call, even when parallel execution of jobs is realized by threads,
High-speed interprocess communication is possible. Moreover, since the threads can be synchronized by the return value from the function, it is not necessary to separately create a processing program for synchronization, and the labor of program development can be reduced. (Third Embodiment) Multifunction machine 100 according to First Embodiment
, The application process, which is the client process, was operating inside the same multi-function peripheral as each control service, which was the server process. In the multi-function peripheral 100 according to the third embodiment, each control service provides a service using an application process of another multi-function peripheral connected to the network as a client process.

FIG. 21 is a block diagram showing the structure of the multifunction machine according to the third embodiment. As shown in FIG. 21, in the third embodiment, a plurality of multifunction peripherals 1300a and 1300b are connected by a network 1340 such as a LAN. Note that in FIG. 21, two multifunction devices 1
Although 300a and 1300b are connected to each other via the network 1340, three or more multi-function peripherals may be connected to each other via the network 1340.

As shown in FIG. 21, the network 134
Each of the multi-function peripherals 1300a and 1300b above 0 has the same configuration as the multi-function peripheral of the first embodiment. Therefore, detailed description of these configurations is omitted.

In the multi-function peripheral of the third embodiment, the first embodiment will be described.
Similarly to the above, mainly application processes such as a copy application 1312, a printer application 1311, a scanner application 1314, and a fax application 1313, and ECS 1324, MCS 1325, FCS 1327,
A control service process such as NCS1328 is a client process using the control service or SRM1323 as a server process, and ECS1324, MCS1325, FCS132 that are operating inside other multi-function peripherals connected to the network.
7, a client process using a control service such as NCS 1328 as a server process.

Further, in the multi-function peripheral of the third embodiment, as in the first embodiment, the ECS 1324 and MCS 13 are mainly used.
25, FCS1327, NCS1328, and other control services and SRM1323 processes become application processes or control services or SRM1323 processes as server processes, but operate inside other multi-function peripherals connected to the network. The application process such as the copy application 1312, the printer application 1311, the scanner application 1314, and the fax application 1313 is also a server process that is a client process.

Since the relationship between the server process and the client process and the respective configurations of the server process and the client process in the multifunction machine of the third embodiment are the same as those shown in FIGS. 2 and 3 described in the multifunction machine of the first embodiment. Detailed description is omitted.

Each control service and SRM 1323
And each application are generated and executed as processes on the general-purpose OS, similarly to the multifunction peripheral 100 of the first embodiment. A plurality of threads are activated inside each process, and parallel execution is realized by switching the CPU occupation time of these threads under the control of a general-purpose OS.

In addition, the multifunction machine 1300a of the third embodiment,
At 1300b, a client process, such as an application, makes a function call to a server process from a thread within the client process to request a service of the server process, such as a control service, and receives the function return value; and Interprocess communication is performed by sending a message from the thread to the server process. Further, function calls and messages can be sent to server processes operating in other multi-function peripherals on the network.

On the other hand, in the server process such as the control service, the interprocess communication with the client process is performed only by transmitting the message. Further, in the server process, it is possible to send a message to a client process on this network by using a process running on another multi-function peripheral on the network as a client process.

The client dispatcher activated by the client process has the same configuration as that of the multi-function peripheral 100 of the first embodiment, and the function return value and the OUT-direction message from another multi-function peripheral connected to the network 1340. Is also monitoring the reception of.

Therefore, in order to perform inter-process communication with the processes of other multi-function peripherals on the network, the function format and message format issued by the client process should be such that information such as the network address can be specified. Provided.

The server dispatcher activated by the server process has the same configuration as the server process in the multifunction machine 100 of the first embodiment, but a client process operating in another multifunction machine connected to the network 1340. Calls and INs from other threads
I am also watching for direction messages.

In the server process, the function handler executed when the function call is received by the server dispatcher returns the function return value to the client process on the network 1340. Therefore, the network of the multifunction machine in which the function call process exists. You can specify the address etc. Also, the message sent from the server process can specify the network address and the like.

Next, the third embodiment configured as described above
In the multi-function peripherals 1300a and 1300b according to the first embodiment, inter-process communication in the case of performing a print operation by using different multi-function peripherals on the network 1340 will be described. FIG. 22 is an explanatory diagram showing a data sequence between the processes of the printer application and the ECS when the printer operation is performed by using the two multifunction peripherals connected to the network according to the third embodiment.

When the printer application process 1311 receives the print request (step S1401), as described in the first embodiment with reference to FIG.
The thread of the printer application process 1311 of 300a sequentially makes a job operation mode setting function call and a job start request function call to the ECS process 1324.

In the third embodiment, at this time, the multifunction machine 13
The printer application process 1311 of 00a is connected to another multifunction machine 1300b via the network 1340.
The job operation mode setting function call and the job start request function call are performed by specifying the network address of (step S1402, S1404).

As a result, the job operation mode setting function call and the job start request function call are not made by the ECS process 1324 of the own multifunction peripheral 1300a, but by the ECS of the multifunction peripheral 1300b designated by the network address.
Sent to process 1324. Then, the thread that made each function call enters a function return wait state.

ECS process 132 of multi-function peripheral 1300b
In 4, the server dispatcher has a network 1340
A job operation mode setting function call and a job start request function call are respectively received via the, and each function handler performs the printer job operation mode setting and printer job start processing. Then, the return value of the job operation mode setting function and the return value of the job open function are transmitted by designating the network address of the multifunction peripheral 1300a (steps S1403 and S1405).

In the printer application process 1311 of the multi function peripheral 1300a, the client dispatcher receives the return value of the job operation mode setting function and the return value of the job open function from the ECS process 1324 of the multi function peripheral 1300b. Then, similarly to the multifunction peripheral of the first embodiment, the thread in the function return waiting state is extracted from the function return waiting queue, and the return value of the job operation mode setting function and the return value of the job open function are extracted. Send to thread.

Subsequent ECS process 1324, MC
Interprocess communication between the S process 1325 and the SRM process 123 is performed within the same multi-function peripheral.
The operation is the same as the printer operation described in the first embodiment. As a result, the actual print processing is performed by the multifunction device 1300b in response to the print request from the multifunction device 1300a.

When the printing process in the multifunction peripheral 1300b is completed, the ECS process 132 of the multifunction peripheral 1300b is completed.
4 sends a job end notification message to the printer application process. At this time, the server dispatcher of the ECS process 1324 sends the job end notification message by designating the network address of the multifunction peripheral 1300a on the network 1340 (step S140).
6).

In the printer application process 1311 of the multi-function peripheral 1300a, the client dispatcher receives the job end notification message transmitted via the network, thereby completing the printer operation.

As described above, in the third embodiment, the inter-process communication is performed between the application process operating on the multifunction peripheral 1300a connected to the network and the ECS process 1324 operating on the multifunction peripheral 1300b, and Thirteen
Since the print processing can be performed by the other multi-function peripheral 1300b on the network 1340 in response to the request generated at 00a, it is possible to realize various functions not only by using the multi-function peripheral on the network, but also by using the multi-function peripheral on the network. it can.

For example, when the printer request of the multi function peripheral 1300a is occupied by the printer engine of the multi function peripheral 1300a, the printer application process judges this and a function for the ECS process 1324. Call the other multifunction device 1 on the network 1340
By performing a process such as switching to a function call to the ECS process 1324 of 300b, it is possible to prevent the time from being required to start printing, and it is possible to improve usability.

In the third embodiment, the inter-process communication in the two multifunction peripherals 1300a and 1300b connected to the network 1340 has been described by taking an example of the printer operation, but in the scanner operation, the copy operation, and the facsimile transmission operation. Also, the scanner application process 1314 and the copy application process 1 in the multifunction machine 1300a
312, fax application process 1313, and ECS
Interprocess communication with the process 1324 is performed in the same manner as in the printer operation.

In addition, the multifunction machine 1300a according to the third embodiment,
In 1300b, application process and ECS process 13
24 and the interprocess communication via the network 1340, the application process and the ECS process 1324 have been described.
Inter-process communication of other control services and system resource manager (SRM) 1323 is performed in the same manner as communication between the application process and the ECS process 1324.

Furthermore, the multifunction machine 1300 of the third embodiment
a, 1300b, application process and network 1
Although the inter-process communication is performed directly with the ECS process 1324 in another multi-function peripheral on the 340, the application process and the ECS process 1324 of the different multi-function peripheral may communicate with each other via the NCS 1328.

That is, the NCS 1328 receives the function call or message from the application process once, specifies the network address of another multifunction peripheral 1300b on the network 1340, and then sends the function call or message to the NCS 1300b of the multifunction peripheral 1300b. Process 1328
It can also be configured to send to.

In this case, in the application process and the ECS process 1324, it is not necessary to add the processing relating to the network address, and the independence between the modules is further enhanced, so that there is an advantage that the multi-function peripheral can have the variability. is there. (Embodiment 4) Multifunction machine 1300 according to Embodiment 3
In a and 1300b, each control service provided a service by using the application process of another multifunction peripheral connected to the network 1340 as a client process. In the multi-function peripheral according to the fourth embodiment, each control service provides a service using the control service of another multi-function peripheral connected to the network as a client process.

In the fourth embodiment, as in the multi-function peripherals 1300a and 1300b of the third embodiment shown in FIG. 21, a plurality of multi-function peripherals are connected by a network 1340 such as a LAN. Each of the multifunction peripherals 1300a and 1300b on the network 1340 according to the fourth embodiment
Has the same configuration as that of the multi-function peripheral according to the first embodiment, and a detailed description of these configurations will be omitted.

In the multifunction machine of the fourth embodiment, the first embodiment
Similarly, mainly application processes such as a copy application 1312, a printer application 1311, a scanner application 1314, and a fax application 1313, and ECS 1324, MCS 1325, FCS 1327, N.
A control service process such as CS1328 is a client process using the control service or SRM1323 as a server process, and further, ECS1324, MCS1325, FCS132 operating inside other multi-function peripherals connected to the network.
7, a client process using a control service such as NCS 1328 as a server process.

Further, in the multi-function peripheral of the fourth embodiment, as in the first embodiment, the ECS 1324 and MCS 13 are mainly used.
25, FCS1327, NCS1328, and other control services and SRM1323 processes are application services, control services, or server processes that use SRM1323 as a client process, but controls running inside other multi-function peripherals connected to the network. It can also be a server process with the service as a client process.

Multifunction machines 1300a and 130 of the fourth embodiment
The relationship between the server process and the client process in 0b and the respective configurations of the server process and the client process are the same as those in FIGS. Is omitted.

Multifunction machines 1300a and 130 of the fourth embodiment
In 0b, when the control service is a client process, a thread in the client process calls a function to the server process in order to request a service of the server process such as another control service, and returns the function return value. Interprocess communication is performed by receiving and sending messages from threads to server processes. Further, function calls and messages can be sent to other control services operating on other multifunction machines on the network 1340 or server processes such as SRM 1323.

The client dispatcher started by the client process such as the control service is
Similar to the multi-function peripherals 1300a and 1300b of the third embodiment, the function return value from the control service or the SRM 1323 (server process) operating in another multi-function peripheral connected to the network 1340 and the reception of the message in the OUT direction are also monitored. ing.

Therefore, in order to perform inter-process communication with the processes of other multi-function peripherals on the network 1340, the format of the function issued by the client process and the format of the message are such that information such as a network address can be specified. Provided by.

The server dispatcher activated by the server process is also the multifunction peripheral 1300a, 130 of the third embodiment.
Network 1 as well as the server process in 0b
It also monitors function calls and IN-direction messages from threads of client processes running on other multi-function peripherals connected to 340.

Also in the fourth embodiment, the ECSs 1324, M serving as the server process and the client process.
In the control services such as CS1325, FCS1327, NCS1328, and SRM1323, the function handler executed when the function call is received by the server dispatcher can specify the network address of the multifunction machine in which the client process that called the function exists. ing. Also, the message sent from the server process can specify the network address and the like.

Next, the fourth embodiment configured as described above
In the multi-function peripherals 1300a and 1300b according to the first embodiment, inter-process communication in the case of performing a facsimile transmission operation using different multi-function peripherals on the network 1340 will be described. FIG. 23 is an explanatory diagram showing a data sequence between the processes of FCS, ECS, and MCS when a facsimile transmission operation is performed using two multifunction machines connected to the network of the fourth embodiment.

When the FCS process 1327 receives the transmission start request from the fax application process 1313 (step S1501), the F of the multifunction peripheral 1300a is processed.
The thread of the CS process 1327 is the network 13
The job operation mode setting function call and the job start request function call are sequentially performed by designating the network address of the other multifunction peripheral 1300b connected to the server 40 (steps S1502 and S1504).

As a result, the job operation mode setting function call and the job start request function call are executed by the EC operating on the multifunction machine 1300b designated by the network address.
It is transmitted to the S process 1324 via the network.

ECS process 132 of multifunction peripheral 1300b
In 4, the server dispatcher has a network 1340
A job operation mode setting function call and a job start request function call are respectively received via the, and each function handler performs the printer job operation mode setting and printer job start processing. Then, the return value of the job operation mode setting function and the return value of the job open function are transmitted by designating the network address of the multifunction peripheral 1300a (steps S1503 and S1505).

FCS process 132 of multi-function peripheral 1300a
In 7, the multi-function device 1 by the client dispatcher
The return value of the job operation mode setting function and the return value of the job open function are received from the ECS process 1324 of 300b. Then, similarly to the multifunction peripheral of the first embodiment, the thread in the function return waiting state is extracted from the function return waiting queue, and the return value of the job operation mode setting function and the return value of the job open function are extracted. Send to thread.

ECS process 132 of multifunction device 1300b
4 makes a memory reservation request function call to the MCS process 1325 (step S1505), and the SRM
A scanner engine resource acquisition request function call is made to the process 123 (step S1506). MCS process 1325 and SRM for such function calls
The processing of the process 1323 is as described in the first embodiment.

ECS Process 132 of Multifunction Device 1300b
In No. 4, when the return value of the resource acquisition function of the scanner engine is received, a scan parameter request message specifying the network address of the multifunction peripheral 1300a is transmitted to the FCS process 1327 of the multifunction peripheral 1300a via the network (step S1507).

FCS Process 132 of Multifunction Device 1300a
In 7, when the scanner parameter confirmation request message is received, the scanner parameter message is transmitted to the ECS process 1324 of the multifunction device 1300b via the network by designating the network address of the multifunction device 1300b (step S150).
8). In ECS process 1324, the server dispatcher receives the scanner parameter message over the network.

Subsequent inter-process communication is performed within the same multi-function peripheral 1300b and is similar to the facsimile transmission described in the first embodiment. This allows
In response to a facsimile transmission start request from the multifunction peripheral 1300a, facsimile transmission is performed by the multifunction peripheral 1300b. When the scanning and facsimile transmission processing in the multifunction device 1300b is completed, the multifunction device 13
The server dispatcher of the ECS process 1324 of 00b designates the network address of the multifunction machine 1300a on the network 1340 and sends a scan end notification message to the FCS process 1327 of the multifunction machine 1300a (step S1509).

FCS process 132 of multi-function peripheral 1300a
In 7, the client dispatcher receives the scan end notification message transmitted via the network 1340, thereby completing the facsimile transmission operation.

As described above, in the multifunction machine of the fourth embodiment,
Inter-process communication is performed between the FCS process 1327 that operates in the multifunction machine 1300a connected to the network and the ECS process 1324 that operates in the multifunction machine 1300b so that other requests on the network 1340 for the request generated by the multifunction machine 1300a. Since the facsimile transmission process can be performed by the multi function peripheral 1300b, various functions can be realized by using the multi function peripheral on the network 1340 as well as the multi function peripheral having the request.

For example, when the facsimile transmission request is generated in the multifunction machine 1300a, if the facsimile engine of the multifunction machine 1300a is occupied by the facsimile reception job, the FCS process 1327 judges this and the ECS process 1324 is notified. By performing processing such as switching the function call to the function call to the ECS process 1324 of the other multifunction peripheral 1300b on the network 1340, the facsimile transmission can be performed immediately and the usability of the multifunction peripheral can be improved.

In the fourth embodiment, the inter-process communication in the two multifunction peripherals 1300a and 1300b connected to the network 1340 has been described by taking the example of the facsimile transmission operation. However, in the scanner operation, the copy operation and the print operation, Also, inter-process communication of the control service in the multifunction machine 1300a and the control service in the multifunction machine 1300b is performed similarly.

In the multifunction machine of the fourth embodiment, the FCS
The interprocess communication between the process 1327 and the ECS process 1324 via the network 1340 has been described.
The inter-process communication via the network 1340 between other control services also enables the FCS process 1327 and the E
The communication is similar to that of the CS process 1324.

Furthermore, in the multifunction machine of the fourth embodiment, FC
The S application process 1327 and the ECS process 1324 in another multi-function peripheral on the network 1340 directly perform inter-process communication. In this case as well, communication between control services of different multi-function peripherals is performed via the NCS process 1328. It may be configured as follows.

As described above, the functions and messages used in the multi-function peripherals of the first to fourth embodiments are all examples, and the present invention is not limited to these, and any function or message can be defined and used. .

[0344]

As described above, according to the invention, it is possible to exchange services and data with each other by inter-process communication while maintaining the independence between the user service and the control service. It is possible to realize a flexible device.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of an image forming apparatus (multifunction peripheral) according to an embodiment of the present invention.

FIG. 2 is a block diagram showing a relationship between a server process and a client process in the multifunction machine according to the first embodiment.

FIG. 3 is a block diagram showing a configuration of a client process which operates in the multi function peripheral according to the first embodiment.

FIG. 4 is a block diagram showing a configuration of a server process that operates in the multifunction peripheral according to the first embodiment.

FIG. 5 is an explanatory diagram showing a data sequence between processes of an application, a control service, and a system resource service when a printer operation is performed by the multifunction peripheral according to the first embodiment.

FIG. 6 is an explanatory diagram showing a relation of transmission / reception of a function and a message among processes of an application, a control service, and a system resource service when performing a printer operation in the multifunction peripheral of the first embodiment.

FIG. 7 is an explanatory diagram showing a data sequence between processes of an application, a control service, and a system resource service when performing a scanner operation in the multifunction machine of the first embodiment.

FIG. 8 is an explanatory diagram showing a relation of transmission / reception of a function and a message between processes of an application, a control service, and a system resource service when performing a scanner operation in the multifunction peripheral of the first embodiment.

FIG. 9 is an explanatory diagram showing a data sequence between processes of an application, a control service, and a system resource service when a copy operation is performed by the multifunction peripheral according to the first embodiment.

FIG. 10 is an explanatory diagram showing a relation of transmission / reception of a function and a message among processes of an application, a control service, and a system resource service when a copy operation is performed in the multifunction machine of the first embodiment.

FIG. 11 is an explanatory diagram showing a data sequence between processes of an application, a control service, and a system resource service when a facsimile transmission operation is performed by the multifunction peripheral of the first embodiment.

FIG. 12 is an explanatory diagram showing a relation of transmission and reception of a function and a message between processes of an application, a control service, and a system resource service when performing a fax transmission operation in the multi-function peripheral of the first embodiment.

FIG. 13 is a block diagram showing in detail the relationship between a server process and a client process operating on the multifunction peripheral 100 according to the second embodiment.

FIG. 14 is a block diagram showing a functional configuration of an image forming apparatus communication program generating apparatus (stub generator) that generates a client process and a server process according to the second embodiment.

FIG. 15 is an explanatory diagram showing a description example of a message file.

FIG. 16 is an explanatory diagram showing an example of a client stub generated by a stub generator.

FIG. 17 is an explanatory diagram showing an example of a server skeleton generated by a stub generator.

FIG. 18 is an explanatory diagram showing an example of a header generated by a stub generator.

FIG. 19 is a flowchart of a server skeleton, client stub, and header generation process.

FIG. 20 is an explanatory diagram showing a sequence of a call and a response with a server program when a function call is made from a client program.

FIG. 21 is a block diagram showing a configuration of a multifunction machine according to a third embodiment.

FIG. 22 is a diagram illustrating a case where the network connection 2 according to the third embodiment is established.
FIG. 9 is an explanatory diagram showing a data sequence between a printer application and an ECS process when performing a printer operation using one multi-function peripheral.

FIG. 23 is a diagram showing a configuration of the network connection 2 according to the fourth embodiment.
FIG. 6 is an explanatory diagram showing a data sequence between processes of FCS, ECS, and MCS when a facsimile transmission operation is performed using two multifunction peripherals.

[Explanation of symbols]

100, 1300a, 1300b Multifunction machine 101,1301 monochrome line printer 102, 1302 color line printer 103, 1303 Scanner 104,1304 facsimile 110,1310 software group 111,1311 Printer application 112, 1312 Copy application 113,1313 Fax application 114,1314 Scanner application 115,1315 Net File App 116, 1316 Process inspection application 120, 1320 platform 121, 1321 General-purpose OS 122, 1322 SCS 123, 1323 SRM 124, 1324 ECS 125,1325 MCS 126, 1326 OCS 127,1327 FCS 128,1328 NCS 129,1329 FCUH 130, 1330 applications 201,1600 client process 202, 1610, 1620 server process 203,1603 Client dispatcher 204, 1611 server dispatcher 1601, 1613, 1623 threads 1602 Client stub 1612, 1622 Server skeleton

Claims (25)

[Claims] 1. An apparatus comprising a hardware resource according to a process to be executed, a process of a user service and a control service related to the process, and having an inter-process communication function for the process, Each of the processes operates as a server process or a client process, the server process has a function that defines one or more services to be provided to the client process, and the client process A device characterized by making a function call when requesting the provision of a service. 2. The control service operates as a server process in which the user service is a client process, and at least two of the user services are provided.
2. The apparatus according to claim 1, further comprising a function that defines a service that is commonly needed, and the user service calls a function when requesting the control service to provide the service. 3. The control service operates as a server process having another control service as a client process, and has a function defining a service commonly required by at least two of the other control services. The apparatus according to claim 1 or 2, wherein the other control service calls a function when requesting the control service to provide the service. 4. The control service operates as the server process as well as the client process.
The apparatus according to claim 1. 5. The apparatus according to claim 1, wherein each process of the user service and the control service includes one or a plurality of threads. 6. The user service and the control service, when operating as the client process, monitor the reception of a function return value for a function call to the server process and call the received function return value to the function call. 6. The apparatus according to claim 5, further comprising a client monitoring means for passing the information to the executed thread. 7. The apparatus according to claim 6, wherein the client monitoring unit is realized by a thread. 8. The client monitoring means further comprises a function return wait queue for temporarily storing an identifier of a thread in a function return value wait state after a function is called, and when the function return value is received from the server process. To
8. The apparatus according to claim 6, wherein the received function return value is transmitted to the thread having the identifier stored in the function return waiting queue. 9. The apparatus according to claim 1, wherein the server process and the client process further perform any of transmission, reception, and transmission / reception of a message regarding an event or a notification. 10. The apparatus according to claim 9, wherein the client monitoring unit further monitors reception of a message from a server process. 11. The apparatus according to claim 10, wherein the client monitoring unit further includes a message handler that executes a process based on the received message. 12. The apparatus according to claim 1, wherein the server process includes a server monitoring unit that monitors a function call from the client process. 13. The apparatus according to claim 12, wherein the server monitoring unit monitors function calls from a plurality of client processes. 14. The server monitoring means comprises a function handler that, when receiving a function call from the client process, executes a process corresponding to the called function. Equipment. 15. The apparatus according to claim 12, wherein the server monitoring unit further monitors reception of a message from a client process. 16. The apparatus according to claim 15, wherein the server monitoring unit further includes a message handler that executes a process based on the received message. 17. A device comprising a hardware resource according to a process to be executed, a process of a user service and a control service related to the process, and having an inter-process communication function for the process, The control service operates as a server process for a client process of another device connected via a network, and has a function defining one or more services provided to the client process of the other device as a server process. A device characterized by. 18. The apparatus of claim 17, wherein each process of the control service comprises one or more threads that execute services provided to client processes of the other apparatus. 19. The apparatus according to claim 17, wherein the control service includes a server monitoring unit that monitors a function call from a client process of the other apparatus. 20. The device according to claim 19, wherein the server monitoring unit further monitors reception of a message from a client process of the other device. 21. The device according to claim 17, wherein the control service further sends a message to a client process of the other device. 22. The apparatus according to claim 17, wherein the control service operates as a server process having a user service operating on the other apparatus as a client process. 23. The apparatus according to claim 17, wherein the control service operates as a server process in which the control service operating on the other apparatus is a client process. 24. The apparatus according to claim 17, wherein the user service operates as a client process in which a control service operating on the other apparatus is a server process. 25. The apparatus according to claim 17, wherein the control service operates as a client process in which the control service operating on the other apparatus is a server process.