JP2006139776A - Information processing system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processing system that can implement a variable architecture and various functions. <P>SOLUTION: The information processing system has one or more programs for information processing. Each of the programs is a process acting as a server process 202 or client process 201. Threads of the server process 202 have functions defining one or more services to be provided for threads of the client process 201. The threads of the client process 201 perform function calls for requesting the threads of the server process 202 to provide the services. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an information processing apparatus, and more particularly to an information processing apparatus in which a plurality of processes perform interprocess communication.

  2. Description of the Related Art In recent years, an image forming apparatus (hereinafter, referred to as “multifunction machine”) in which functions of apparatuses such as a printer, a copy machine, a facsimile machine, and a scanner are housed in a single housing is generally known. This multifunction device is provided with a display unit, a printing unit, an imaging unit, and the like in one casing, and is provided with three types of software respectively corresponding to a printer, a copying machine, and a facsimile machine. It operates as a copy, scanner or facsimile machine.

  A conventional multi-function machine has a configuration in which software (including a general-purpose OS) corresponding to a printer, a copy, a scanner, and a facsimile machine is provided separately, and development of each software requires a lot of time.

  For this reason, the applicant can use the software group called the driver that drives the hardware interface, the manager software group for efficiently using the common hardware assets such as the memory / timer, and each application. A multi-function machine comprising a system utility software group and a real application such as a printer / scanner / fax transmission / fax reception using these driver software group, manager software group, and utility software group (for example, patent literature) 1 or Patent Document 2).

  However, the multifunction peripherals described in Patent Document 1 and Patent Document 2 include a driver / software group, a manager / software group, and a utility / software group in a library, and can be a main body that controls execution of hardware resources. There wasn't.

  Accordingly, the applicant has a plurality of applications that have hardware resources used in image forming processing such as a display unit, a printing unit, and an imaging unit, and perform processing unique to each user service such as a printer, copy, or facsimile. When installing and providing user services by interposing between these applications and hardware resources, management, execution control and image formation processing of hardware resources that are shared by at least two of the applications are performed. Invented a multi-function machine (see, for example, Patent Document 3) having a platform composed of various control services.

  The user service is a service related to image formation provided to the user. The control service refers to a service that provides hardware resources related to image formation to an application.

According to this multi-function peripheral, it is possible to improve the efficiency of software development by providing a platform for performing management, execution control, and image formation processing of hardware resources commonly required by at least two applications. As a result, the productivity of the entire apparatus can be improved.
JP-A-9-51398 JP-A-9-91102 JP 2002-82806 A

  Such a multi-function peripheral has a control service that provides services that are commonly required by at least two of the applications. Therefore, it is possible to change functions, add functions, or add or change hardware resources in the future. It is desirable to be able to easily add or change for each application or control service in order to respond flexibly to the above. 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.

  In other words, a multifunction device has a variety of functions such as printers, copiers, facsimiles, scanners, etc., but if some of the functions fail or specification changes occur, all applications or all control services If you have to modify these modules, the work effort will be excessive.

  Also, even if new functions are added to the MFP in the future, if it is necessary to change all control services and all application modules to add some functions, the program development effort will be excessive. End up. For this reason, it is necessary for each application and control service module operating on the multifunction peripheral to maintain the independence between the modules while realizing the transmission and reception of services and data with each other.

  In other words, if there is no independence for each application and each control service, it will be difficult to provide only the necessary applications and necessary control services, and the configuration of the MFP will be able to flexibly respond to function changes and additions. Cannot have variability.

  Also, if each application and each control service is not independent, it becomes difficult to design and construct each application and control service, and a wide variety of functions cannot be provided.

  The present invention has been made in view of the above, and an object thereof is to obtain an information processing apparatus capable of realizing a variable architecture and various functions.

  In order to achieve the above object, the present invention is an information processing apparatus having one or more programs for performing information processing, each of the programs including one or more threads operating as a server process or a client process. The server process thread has a function that defines one or more services to be provided to the client process thread, and the client process thread provides a service to the server process thread. It is characterized in that a function call is made when requesting.

  According to the present invention, inter-process communication by function call can be realized between one or a plurality of programs. For this reason, service and data can be exchanged with each other by inter-process communication while maintaining independence between the programs, and an information processing apparatus with various functions can be provided.

  Even if only a part of the program module is changed, or when a program is added as necessary, the function is implemented on the module side that is the server process, and the function is called on the module side that is the client process. If the interface is secured, services and data can be exchanged.

  For this reason, addition or change of a program can be easily realized, and an information processing apparatus having variability can be configured.

  Furthermore, since each of the programs is a process that operates as a server process or a client process, by operating a plurality of programs as separate processes, other processes that are operating even when the processes of other programs are stopped Is not affected.

  For this reason, even when some processes are stopped, it is possible to continue to provide other composite services, and it is possible to prevent all composite services from becoming unavailable.

  Here, the “server process” refers to a process that provides a requested service in response to a request from another process, and any program can operate as a server process as long as the service is provided.

  The “client process” refers to a process that receives a service from such a server process, and any program can operate as a client process as long as the service is received.

  The “function” is to execute processing and setting requested by the server process in response to a service processing request to the server process and a predetermined setting value setting request by the server process.

  Further, the present invention is an information processing apparatus having one or a plurality of programs for performing information processing, each of the programs is a process including one or a plurality of threads that operate as a server process or a client process, The server process operates as a server process for a client process that operates on another information processing apparatus connected to a network, and provides one or a plurality of server processes as a thread of a server process to a thread of a client process of the other information processing apparatus It has a function that defines a service.

  According to the present invention, the program can realize inter-process communication using a function call as a server process using a process operating on another information processing apparatus on the network as a client. Services can be provided not only to processes but also to information processing apparatuses on the network, and various functions can be realized.

  In the present invention, the configuration of the information processing apparatus in which the program serving as the server process is operating is not limited as long as the program can be installed. That is, the information processing apparatus only needs to have one program that provides a service.

  According to the present invention, services and data can be exchanged with each other by inter-process communication while maintaining independence between programs, and various functions can be realized.

Exemplary embodiments of an image forming apparatus according to the present invention are explained in detail below with reference to the accompanying drawings.
(Embodiment 1)
FIG. 1 is a block diagram showing a configuration of an image forming apparatus (hereinafter referred to as “multifunction machine”) according to Embodiment 1 of the present invention. As shown in FIG. 1, the multi-function peripheral includes a monochrome line printer (B & W LP) 101, a color line printer (Color LP) 102, a scanner 103, hardware resources such as a facsimile 104, and the 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 a system resource that manages one or a plurality of hardware resources and arbitrates the acquisition request from the control service. A manager (SRM) 123 and a general-purpose OS 121 are included.

  The control service is formed 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, an OCS (operation panel control service) 126, and an FCS. (Fax Control Service) 127 and NCS (Network Control Service) 128. The platform 120 has an application program interface (API) that can receive a processing request from the application 130 by a predefined function.

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

  The SRM 123, together with the SCS 122, controls the system and manages resources, and includes engines such as a scanner unit and a printer unit, memory, HDD files, host I / O (Centro I / F, network I / F, IEEE 1394 I / O). (F, RS232C I / F, etc.) arbitration is performed according to a request from a higher layer using hardware resources, and execution control is performed.

  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 used. Tell the upper layer that it is possible. The SRM 123 also schedules the use of hardware resources in response to requests from higher layers, and directly implements the request contents (for example, paper conveyance and image forming operation, memory allocation, file generation, etc. by the printer engine). .

  The SCS 122 performs application management, operation unit control, system screen display, LED display, resource management, and interrupt application control. 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), compresses and decompresses image data, and the like. The OCS 126 is a module that controls an operation panel serving as information transmission means between the operator and the main body control.

  FCS 127 performs facsimile transmission / reception using PSTN / ISDN network from each application layer of the system controller, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, and fusion transmission / reception. API is provided. In the FCS 127, the FCU handler 129 (FCUH) that is the subprocess is started. The FCUH 129 controls a device driver of the facsimile engine when a facsimile is transmitted / received by a command from the FCS 127.

  The NCS 128 is a module group for providing a service that can be commonly used for applications that require network I / O. The NCS 128 distributes data received by each protocol from the network side to each application, and distributes data from the application. It mediates when transmitting to the network side.

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

  Each of these control services, SRM 123, and each application is generated and executed on a general-purpose OS as a process. In each process, a plurality of threads are activated, and parallel execution is realized by switching the CPU occupation time of these threads under the management of the general-purpose OS. Each application process and each control service process send and receive various messages and data and call functions by inter-process communication described later.

  FIG. 2 is a block diagram illustrating a relationship between a server process and a client process that operate on the multifunction peripheral according to the first embodiment. Here, the server process 202 refers to 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 MFP according to the first embodiment, the client process 201 mainly includes application processes such as the copy application 112, the printer application 111, the scanner application 114, and the fax application 113, and control service processes such as the ECS 124, MCS 125, FCS 127, and NCS 128. Thus, the process of the control service and the SRM 123 becomes the server process 202 mainly.

  That is, when each application receives service provision 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.

  The application process, the control service process, and the SRM process can all be the server process 202 and the client process 201 without being limited to these examples. That is, when these processes request a service from any other process, they operate as a client process 201, and when these processes provide a service by a request from another process, they operate as a server process 202. It will be.

  As shown in FIG. 2, a plurality of threads are activated in any of these applications, the control service, and the SRM 123 process. Since each process has a plurality of threads, when it receives a request from another process, it operates as a server process 202 with the other process as a client process 201. When a service is requested from a process, the process operates as a client process 201 with the other process as a server process 202.

  Each process can also be a server process 202 having a plurality of processes as client processes 201 at the same time. Further, each process can be a client process 201 that receives services from a plurality of server processes 202 at the same time.

  As shown in FIG. 2, in order to request the service of the server process 202, the client process 201 makes a function call to the server process 202 from a thread in the client process and receives the function return value. Communicate.

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

  For this reason, the control service such as ECS 124, MCS 125, FCS 127, and NCS 128 that can be the server process 202 and the service provided to the client process 201 are pre-installed as function handlers 403 to be described later for each service. When requesting these services from the client process 201, the server process 202 can be provided with a service by calling a function for each service (by making a function call). Yes.

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

  In the message direction, there are “IN”, “OUT”, and “SELF”, “IN” means a message transmitted from the client process 201 to the server process 202, and “OUT” is a message from the server process 202 to the client process. This means a message to be sent to 201. “SELF” means a message to be transmitted to its own process.

  The “function” is issued when a predetermined processing request is made from the client process 201 to the server process 202 or when a predetermined setting request is made, and a return value is returned to the function call. is there.

  The thread of the client process 201 calls a function provided from the server process 202 in advance. Upon receiving the function call, the server process 202 executes processing corresponding to the requested function and transmits the execution result to the client dispatcher 203 of the client process 201 as a function return value. In addition, the function return value is a structure, and the structure includes a function ID for identifying the function in addition to the return value.

  The client dispatcher 203 is a thread that monitors reception of an OUT-direction message or function return value from the server process 202. The client process 201 activates one client dispatcher 203 for each server process 202 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 a detailed configuration of the client dispatcher. The client dispatcher 203 activates a message handler 302, an error handler 301, and a default handler 303 on the thread.

  The message handler 302 performs processing on the received message, and there are a plurality of separate message handlers 302 for each message ID. For this reason, 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. The processing content of the message handler 302 includes, for example, processing such as notifying the thread that has performed the function call of the message content, but different processing content is 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 called when a message with a message ID for which the corresponding message handler 302 is not registered is received, and performs processing such as notifying the thread of the message.

  The client dispatcher 203 holds a function return waiting queue 304, and manages the function return value and the function return waiting thread 305 by using the function return waiting queue 304. In other words, the thread of the client process 201 makes a function call to the server process 202. After the function call, the function waits until a function return value is received, and the subsequent processing is interrupted.

  When a function call is made from the thread 305, the client dispatcher 203 registers the identifier (thread ID, etc.) of the thread 305 together with the function ID of the function in the function return waiting queue 304. When the client dispatcher 203 receives the function return value from the server process 202, the client dispatcher 203 searches the function return waiting queue 304 using the function ID as a key, and waits for the reception of the received function return value. An identifier 305 (such as a thread ID) is detected. Then, the client dispatcher 203 transmits the received function return value to the thread with the detected identifier (thread ID). The thread that has 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 every time a function return value is received.

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

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

  The function handler 403 executes specific processing of the function, and a plurality of function handlers 403 exist for each function. Upon receiving a function call from the client process 201, the server dispatcher 204 activates a function handler 403 corresponding to the received function, executes the processing requested by the client process 201 by the function handler 403, and sends the function return value to the client process. The message is sent to the client dispatcher 203 of 201.

  The message handler 402 performs processing on the received message, and a plurality of message handlers exist for each message ID. When receiving a message, the server dispatcher 204 determines a message ID included in the received message, and calls the message handler 402 of the corresponding message ID. The processing content of the message handler 402 includes, for example, processing such as notifying the thread of the message content, but different processing content is defined for each message.

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

  Next, the interprocess communication in the printer operation, the scanner operation, the copy operation, and the facsimile transmission operation that is actually performed in the MFP 100 according to the first embodiment will be specifically described.

  First, the inter-process communication of the printer application 111, ECS 124, MCS 125, and SRM 123 in the printer operation will be described. FIG. 5 is an explanatory diagram showing a data sequence between processes of the printer application, ECS, MCS, and SRM in the case where the printer operation is performed by the multifunction peripheral according to the first embodiment. FIG. 6 is an explanatory diagram showing the relationship between functions and messages between each process.

  As illustrated in FIG. 6, a printer application process 111, an ECS process 124, an MCS process 125, and an SRM process 123 are operating in the multifunction peripheral 100. These processes are generated when the MFP 100 is activated. FIG. 6 shows only processes used in the printer operation. Actually, other application processes and other control service processes are also generated when the MFP 100 is activated.

  The printer application process 111 is activated when the MFP 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. Therefore, a client dispatcher that receives a message or a function return value from the ECS process 124 and notifies a thread in the process is started as a thread. Is done.

  The ECS process 124 becomes a server process using the printer application process 111 as a client process and a client process using the MCS process 125 and the SRM process 123 respectively as server processes during printer operation. Therefore, the ECS process 124 includes a server dispatcher thread that receives function calls and messages from the printer application process 111 and transmits messages and function return values to the printer application process 111, and the MCS process 125 or the SRM process 123. A client dispatcher that receives messages and function return values and manages return values, and a plurality of threads that perform processing related to job control and engine control are operating.

  The MCS process 125 becomes a server process using the ECS process 124 as a client process and a client process using the SRM process 123 as a server process during printer operation. Therefore, within the MCS process 125, a server dispatcher thread that receives function calls and messages from the ECS process 124 and transmits messages and function return values to the ECS process 124, and messages and function return values from the SRM process 123. A client dispatcher that performs reception and return value management and a plurality of threads that perform processing related to memory control or hard disk control are operating.

  The SRM process 123 is a server process that uses the ECS process 124 or the MCS process 125 as a client process during printer operation. Within the SRM process 123 is a server dispatcher thread that receives function calls and messages from the ECS process 124 or MCS process 125 and sends messages and function return values to the ECS process 124 or MCS process 125, and other engine resource controls. A plurality of threads that perform various processes related to the above are operating.

  In the printer application process 111 according to the first embodiment, processing for making function calls for job operation mode setting and job start request is made one thread. Further, in the ECS process 124, a process for repeatedly making a memory image information request function call for the number of printed sheets is set as one thread, and a process for making a resource acquisition request function call is set as one thread. In the MCS process 125, a process for 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 determined by each program.

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

  Thereafter, the thread 1 waits to receive 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 necessary for operating the scanner, plotter, finisher, and the like. The operation conditions of the job generated from the printer conditions such as the print paper size, the number of copies, and the paper feed tray are set. It is determined.

  For the sake of simplification of description, the identifier (thread ID) of a thread that has made a function call waiting state by making a function call to the server process is registered in the function return waiting queue together with the function ID by the client dispatcher. This is simply expressed as “the thread is waiting for a function return”.

  In the ECS process 124, the server dispatcher receives a job operation mode setting function call from the printer application process, and starts a job operation mode setting function handler on the thread of the server dispatcher. Then, the above-described job operation mode is set for the printer job newly generated by the job operation mode setting function handler, and a 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, searches the function return queue for the thread 1 waiting for the function return value, and sets the job operation mode setting function. The return value is extracted and transmitted to the thread 1.

  For the sake of simplification of description, the identifier of the thread waiting for function return (thread ID) is retrieved from the function return queue by the client dispatcher, and the thread with the retrieved identifier (thread ID) is retrieved from the client dispatcher. Receiving a function return value is simply expressed as “a thread receives a function return value via a client dispatcher”.

  When the thread 1 receives the function return value for setting the job operation mode from the client dispatcher, the job start request function is called to the ECS process 124 in order to exit the return waiting state and make a job start request (step S503). Waiting for return.

  In the ECS process 124, the server dispatcher receives a job start request function call from the printer application process 111, starts a job start request function handler on the server dispatcher thread, and performs job start processing by the job start request function handler. The function return value is transmitted 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 transmits a memory image information request message to the MCS process 125 in the thread 3 in order to acquire 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 transmitted to the ECS process 124 (step S505).

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

  On the other hand, in the MCS process 125, after the image data is transmitted to the ECS process 124, a memory acquisition request function call is made to the SRM process 123 in the thread 5 in order to secure an image memory (step S506), and a return waiting state is established. It becomes. In the SRM process 123, the server dispatcher receives a memory acquisition request function call from the MCS process 125, activates a memory acquisition request function handler, reserves image memory for printing by this memory acquisition request function handler, and returns a 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 the print data of the first page is received from the MCS process 125, a resource acquisition request function call is made to the SRM process 123 in the thread 4 in order to acquire the printer engine resource (step S507). , The function returns waiting state. In the SRM process 123, the server dispatcher receives a resource acquisition request function call from the ECS process 124 and activates the resource acquisition request function handler, occupies the printer engine by the resource acquisition request function handler, and sends the function return value to the ECS process 124. Send. 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 thread 4 receives the return value of the resource acquisition request function via the client dispatcher.

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

  In this way, the inter-process communication of the printer operation is performed. Here, as shown in FIG. 5, when another print request 2 is transmitted from the NCS to the printer application process 111 during the print process for the print request 1. Will be described. (Step S521).

  At this time, the printer application process 111, the ECS process 124, the MCS process 125, and the SRM process 123 perform inter-process communication similar to the function call described above (steps S522, S523, and S524).

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

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

  Next, inter-process communication of the scanner application 114, the ECS 124, the MCS 125, and the SRM 123 in the scanner operation performed by the multifunction peripheral 100 according to the first embodiment will be specifically described. FIG. 7 is an explanatory diagram showing a data sequence between each process of the scanner application, ECS, MCS, and SRM when the scanner operation is performed in the multi-function peripheral according to the first embodiment. FIG. 8 is an explanatory diagram showing the relationship between functions and messages between processes.

  As illustrated in FIG. 8, the scanner application process 114, the ECS process 124, the MCS process 125, and the SRM process 123 are operating in the multifunction peripheral 100. These processes are generated when the MFP 100 is activated. FIG. 8 shows only processes used in the scanner operation, and other application processes and other control service processes are actually generated when the MFP 100 is started up.

  The scanner application process 114 is activated when the MFP 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. For this reason, a thread of a client dispatcher for the ECS process 124 is activated.

  The ECS process 124 becomes a server process using the scanner application process 114 as a client process and a client process using the MCS process 125 and the SRM process 124 as server processes during the scanner operation. Therefore, 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 other processes related to job control or engine control. Thread is running.

  The MCS process 125 becomes a server process using the scanner application process 114 and the ECS process 124 as client processes during the scanner operation. Therefore, a server dispatcher thread for the scanner application process 114 and the ECS process 124 and a plurality of threads for performing processing related to memory control or hard disk control are operating in the MCS process 125.

  The SRM process 123 becomes a server process using the ECS process 124 as a client process. For this reason, a server dispatcher thread for the ECS process 124 and a plurality of other threads that perform processing related to engine resource control operate in the SRM process 123. Yes.

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

  In the scanner application process 114, a file open request function call at the time of reading a scanned image, a process for making a work area securing request function call and a page open request function call, a process for making a read request function call, a page close request function call A series of processes for performing a page deletion request function call, a work area deletion request function call, a file close request function call, and a file deletion request function call are made into one thread.

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

  When there is a scan request to the scanner application process 114, the scanner application process 114 generates a new scanner job and performs a job open request function call to the ECS process 124 in the thread 1 (step S701). Thereafter, the thread 1 enters a function return waiting state, and the identifier (thread ID) of the thread 1 is registered in the function return waiting queue together with the function ID of the function called by the client dispatcher.

  In parallel with this, the scanner application process 114 performs a file generation request function call to the MCS process 125 by the thread 2 (step S702). Thereafter, the thread 2 enters a function return waiting state, and similarly, the identifier (thread ID) of the thread 2 is registered in the function return waiting queue.

  In the ECS process 124, the server dispatcher receives a job open request function call from the scanner application process 114, and starts a job open request function handler on the server dispatcher thread. Then, the job is opened by the job open request function handler, and the function return value is transmitted 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 generates a file on the hard disk for temporarily storing the scanned image by the file generation request function handler. 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, receives the return value of the file generation request function from the MCS process 125, and receives a job open request from the function return value queue. A thread 1 waiting for a function return and a thread 2 waiting for a file generation request function return are detected, the return value of the job open request function is transmitted to the thread 1, and the return value of the file generation request function is transmitted to the thread 2.

  When the thread 1 receives the return value of the job open request function from the client dispatcher, the thread 1 exits the return waiting state and calls the job operation mode setting request function to the ECS process 124 in order to set the job operation mode (step S703). Thread 1 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 scanner application process 114, sets the above-described job operation mode in the scanner job by the job operation mode setting request function handler, and sets the function return value to the scanner. It is transmitted to the client dispatcher of the application 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 thread 1 that has left the function return wait state, a job start request function call is made to the ECS process 124 (step S704), and thread 1 enters a function return wait state. In the ECS process 124, the server dispatcher receives the job start request function call, performs job start processing by the job start request function handler, and transmits 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, the ECS process 124 makes a resource acquisition request function call to the SRM process 123 in the thread 3 due to the scanner engine resource struggle (step S705), and enters a function return waiting state. The ECS process 124 calls a page generation request function call to the MCS process 125 in the thread 4 in order to secure a memory for storing the scanned image in units of pages in parallel (step S706), and waits for a function return. It becomes. At this time, the identifiers (thread IDs) of the threads 3 and 4 are stored in the function return waiting 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 occupies the scanner engine and transmits the function return value to the ECS process 124 by the resource acquisition request function handler. In the MCS process 125, the server dispatcher receives the page generation request function call, reserves one page of memory by the page generation request function handler, opens the reserved page, and transmits 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 receives the return value of the page generation request function from the MCS process 125. Then, the thread 3 waiting for the function return 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.

  Upon receiving the function return value, the thread 4 exits the return waiting state, and then transmits a document feed-in instruction message to the scanner engine (step S707), thereby starting the document reading operation by the scanner. When the document reading operation for one page is completed, a 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 a return wait state is entered.

  When 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 transmits the function return value to the client dispatcher of the ECS process 124. .

  The client dispatcher of the ECS process 124 receives the return value of the page close request function, and the thread 4 waiting for the function return receives the return value of the page close request function via the client dispatcher. As a result, the thread 4 exits the function return waiting state and repeats the above-described processing from the page generation request function call to the page close request function call (steps S706 to S709) for the number of originals.

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

  The client dispatcher of the scanner application process 114 receives the scan processing completion notification message and the job end notification message in order from the ECS process 124 and notifies the thread 1 of them. 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 enters a function return waiting state.

  In the MCS process 125, when the server dispatcher receives the file information registration request function call, the file information registration request function handler executes the file name, the file name, File information such as the storage destination is registered, and the function return value is transmitted 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, it makes a file close request function call to the MCS process 125 (step S714), and enters a function return waiting state. In the MCS process 125, the file dispatch request function call is received by the server dispatcher, the file of the scan image is closed by the file close request function handler, and the function return value is transmitted to the scanner application process 114. When the scanner application process 114 receives the return value of the file close request function, the scanning process ends.

  Next, in the scanner application process 114, the following processing is performed in order to read out the stored scan image. First, in the thread 6, a file open request function call for opening a scan image file, a work area allocation request function call for securing a working memory, and a page open request function call are sequentially performed on the MCS process 125. (Steps S715 to S717). As described above, after making each function call, the thread 6 enters a function return wait state, and exits the return wait state upon notification of a function return value, and performs the next function call.

  The server dispatcher of the MCS process 125 sequentially receives a file open request function call, a work area allocation request function call, and a page open request function call from the thread 6 of the scanner application process 114, and opens the scan image file, The secure processing and page open processing are performed by each function handler, and each function return value is transmitted to the scanner application process 114. In the scanner application process 114, the return values of the file open request function, the work area allocation request function, and the page open request function are sequentially received by the client dispatcher, and the thread 6 receives the function return value via the client dispatcher.

  In the scanner application process 114, a read request function call is performed in the thread 7 to read image data from the scanned image file (step S718), and the thread 7 enters a function return waiting state. Further, the thread 8 performs a page close request function call to the MCS process 125 (step S719), and the thread 8 enters a 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 end of the page open process, which is a request from the thread 6, reads out image data from the scanner image file by the read request function handler, and The function return value is transmitted to the scanner application process 114 together with the data. In the scanner application process 114, when the thread 7 receives the return value of the read request function via the client dispatcher, it 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 a request from the thread 7, is completed, the function handler of the page close request function received from the thread 8 of the scanner application process 114 is activated, and the opened page data Close processing is performed, and the function return value is transmitted 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 waiting state. As a result, the thread 8 sequentially performs a page deletion request function call, a work area deletion request function call, a file close request function call, and a file deletion request function call (steps S720 to S723).

  The MCS process 125 receives these function calls in order, and deletes page data, deletes the working memory, closes the scanned image file, and deletes the scanned image file respectively by the function handler corresponding to the received function call. Processing 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, whereby the scan image reading process is completed.

  Next, the interprocess communication of the copy application 112, the ECS 124, the MCS 125, and the SRM 123 in the copy operation performed by the multifunction peripheral 100 according to the first embodiment will be specifically described. FIG. 9 is an explanatory diagram showing a data sequence between processes of the copy application, ECS, MCS, and SRM when a copy operation is performed by the multifunction peripheral according to the first embodiment. FIG. 10 is an explanatory diagram showing the relationship between functions and messages between processes.

  As shown in FIG. 10, a copy application process 112, an ECS process 124, an MCS process 125, and an SRM process 123 are operating in the multifunction peripheral 100. These processes are generated when the MFP 100 is activated. FIG. 10 shows only processes used in the copy operation, and in fact, other application processes and other control service processes are also generated when the MFP is activated.

  The copy application process 112 is activated when the MFP 100 is activated, and a plurality of threads are activated 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. For this reason, a client dispatcher thread for the ECS process 124 is activated.

  The ECS process 124 becomes a server process using the copy application process 112 as a client process and a client process using the MCS process 125 and the SRM process 123 as server processes, respectively, during a copy operation. Therefore, in the ECS process 124, a server dispatcher thread for the copy application process 112, a client dispatcher thread for the MCS process 125, a client dispatcher thread for the SRM process 123, and other processes related to job control and engine control. Thread is running.

  During the copy operation, the MCS process 125 becomes a server process using the ECS process 124 as a client process and a client process using the SRM process 123 as a server process. Therefore, in the MCS process 125, a server dispatcher thread for the ECS process 124, a client dispatcher thread for the SRM process 123, and a plurality of other threads for performing various processes relating to memory control and hard disk control operate.

  The SRM process 123 becomes a server process using the ECS process 124 and the MCS process 125 as client processes. Therefore, in the SRM process 123, a process related to a thread of a server dispatcher for the ECS process 124 and the MCS process 125 and other resource control of the engine. Multiple threads are running.

  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 in one thread. It is said.

  In the ECS process 124, a process for making a memory allocation request function call, a process for making a resource acquisition request function call, and a document feed-in process are each in one thread. In the MCS process 125, a process for making a memory acquisition request function call is one thread. Note that the processing in each of these threads is an example even during the copy operation, and can be arbitrarily determined by each program.

  When there is a copy request, the copy application process 112 generates a new copy job and makes a job open request function call to the ECS process 124 in the thread 1 (step S901). As a result, the thread 1 enters a function return waiting state and is registered in the function return waiting queue together with the function ID of the job open request function called by the client dispatcher.

  In the ECS process 124, the server dispatcher receives a job open request function call from the copy application process 112, and starts a job open request function handler on the server dispatcher thread. 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 waiting for the function return. Then, the return value of the job open request function is transmitted to the retrieved thread 1.

  When the thread 1 receives the return value of the job open request function from the client dispatcher, the thread 1 makes a job operation mode setting function call to the ECS process 124 in order to exit the return waiting state and set the job operation mode (step S902). , The function returns waiting state.

  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 time, the identifier of the thread 1 (thread ID) is registered together with the function ID of the job operation mode setting function in the function return queue, and the identifier of the thread 2 (thread ID) is registered together with the function ID of the job start request function. Registered by dispatcher.

  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-described job operation mode in the copy job by the job operation mode setting function handler, and sets the function return value to the copy application process. 112 to the client dispatcher. Also, the server dispatcher receives the job start request function call, performs job start processing by the job start request function handler, and transmits a 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 value 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.

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

  In the MCS process 125, when the server dispatcher receives the memory allocation request function call, the MCS process 125 allocates an area on the memory having the size specified by the memory allocation request function handler, and transmits 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, occupies the scanner engine and the printer engine by the resource acquisition request function handler, and transmits the function return value to the ECS 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 receives the return value of the resource acquisition request function from the SRM process 123. 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 waiting state.

  When the return value of the resource acquisition request function is received and the scanner engine and printer engine are occupied by the copy job, the ECS process 124 feeds the document to the scanner engine in thread 5 (step S907), thereby copying. The original document scanning process is started.

  When the scanning process of the document is completed, the scanner engine transmits a scanning end notification message to the thread 5 of the ECS process 124 (step S908), and the printing process of the scanned image is started by the printer engine. When the print processing of the scanned image is completed, the printer engine transmits a print end notification message 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, the thread 5 transmits a job end notification message indicating the end of scanning 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 transmits 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, activates a message handler, and notifies the thread 2 of each job end notification message. This completes the copy operation for one page of the document.

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

  In the ECS process 124, the job dispatch request function call is received by the server dispatcher, the copy job in the open state is closed by the job close request function handler, and the function return value is transmitted to the copy application process 112.

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

  If the scanner application process 114 receives a scan request during the copying operation described above, the following processing is performed. For example, consider a case where a scanning request is made to the scanner application process 114 after making a resource acquisition request function call for the scanner engine and printer engine from the ECS process 124 to the SRM process 123 in the copying operation.

  In this case, in the scanner operation in FIG. 7 described above, the scanner engine resource acquisition request function call is made from the ECS process 124 to the SRM process 123. However, since the scanner engine is occupied by the copy job, it is acquired by the scanner job. Can not do it.

  Therefore, in the scanner job, the return value of the resource acquisition request function is transmitted to the ECS process 124 after the copy job is completed and the scanner engine is released. During this time, the thread that has made 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. Similarly, when a print request is made to the printer application process 111 after the printer engine is occupied by a copy job during the copy operation, the print operation is similarly suspended until the copy operation is completed.

  The scanner operation during the copy operation has been described with reference to an example in which the scanner job cannot be acquired by the scanner job. In addition, a page generation request function call is made from the ECS process 124 to the MCS process 125 in the scanner job. Even if the page is not generated due to insufficient memory because the copy job is using memory, the thread that made the page generation request function call will be in a function return waiting state and the copy operation will be completed. Until the scanner operation is interrupted.

  Next, the interprocess communication of the fax application 113, the FCS 127, the ECS 124, the MCS 125, and the SRM 123 in the facsimile transmission operation performed by the multifunction machine of the first embodiment will be specifically described. FIG. 11 is an explanatory diagram showing a data sequence between each process of the fax application, FCS, ECS, MCS, and SRM when a copying operation is performed in the multifunction machine of the first embodiment. FIG. 12 is an explanatory diagram showing the relationship between functions and messages between processes.

  As illustrated in FIG. 12, a fax application process 113, an FCS process 127, an FCUH process 129, an ECS process 124, an MCS process 125, and an SRM process 123 are operating in the multifunction peripheral 100. These processes are generated when the MFP 100 is activated. FIG. 12 shows only processes used in the fax transmission operation, and actually 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 MFP 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 that uses the FCS process 127 as a server process. For this reason, a client dispatcher thread for the FCS process 127 is activated.

  The FCS process 127 becomes a server process using the fax application process 113 as a client process and a client process using the ECS process 124 and the FCUH process 129 as server processes during a facsimile transmission operation. Therefore, in the FCS process 127, a server dispatcher thread for the fax application process 113, a client dispatcher thread for the ECS process 124, a client dispatcher thread for the FCUS process 129, and other processes related to facsimile communication control are performed. The thread is working.

  The FCUH process 129 is a sub-process of the FCS process 127, and becomes a server process using the SRM process 123 and the FCS 127 as client processes during facsimile transmission operation. For this reason, a server dispatcher thread for the SRM process 123 and the FCS 127 and a plurality of threads for performing processing such as instructions for the facsimile device driver are operating in the FCUH process 129.

  During the facsimile transmission operation, the ECS process 124 becomes a server process using the FCS process 127 as a client process and a client process using the MCS process 125 and the SRM process 123 as server processes, respectively. For this reason, the ECS process 124 includes a server dispatcher thread for the FCS process 127, a client dispatcher thread for the MCS process 125, a client dispatcher thread for the SRM process 123, and a plurality of other processes related to job control and engine control. The thread is working.

  The MCS process 125 becomes a server process using the ECS process 124 as a client process and a client process using the SRM process 123 as a server process during a facsimile transmission operation. Therefore, in the MCS process 125, a server dispatcher thread for the ECS process 124, a client dispatcher thread for the SRM process 123, and a plurality of threads that perform processing related to memory control and hard disk control are operating.

  The SRM process 123 is a server process that uses the ECS process 124 and the MCS process 125 as client processes, and a client process that uses the FCUH process 129 as a server process. Therefore, a server dispatcher thread for the ECS 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 operate in the SRM process 123. Yes.

  In the fax application 113 according to the first embodiment, a process for making a transmission start request function call and a process for making a transmission mode change request are each in one thread. In the FSC process 127, a series of processing for performing a job operation mode setting function call and a job start request function call during fax transmission operation, processing for receiving a scan parameter request message and transmitting scan parameters, EOM (with next page), Each thread performs a process of notifying a next page information message such as EOF (no next page).

  In the ECS process 124, a series of processes for making a memory allocation request function call and a resource acquisition request function call, and a process for transmitting a scan / feed-in process generation instruction message are each handled as one thread. In the MCS process 125, processing for making a memory allocation request function call and processing for transmitting other messages are set as 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 each set as one thread. In the FCUH 129, processing for transmitting a next page information message such as EOM or EOF is set as one thread. It should be noted that the processing in each thread is an example even during the facsimile transmission operation, and can be arbitrarily determined by each program.

  When there is a facsimile transmission request, the fax application process 113 generates a new facsimile transmission job, performs a transmission start request function call from the thread 1 to the FCS process 127 (step S1101), and the thread 1 waits for a function return. It becomes. In the FCS 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 uses the thread 3 of the transmission start request function handler to execute the job operation mode for the MCS process 125. A setting request function call is performed (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 to the facsimile transmission job by the job operation mode setting request function handler, and sets the function return value to the FCS process. 127 to the client dispatcher.

  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, and 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.

  The MCS process 125 that has received this job start request function call makes a memory allocation request function call to the MCS 125 by the job start request function handler (step S1104), and makes a resource acquisition request function call to the SRM process 123 (step S1104). S1106). The processing of the MCS process 125 and SRM process 123 that have received these function calls and the processing accompanying reception of the return value of each function in the ECS process 124 are the same as the processing at the time of the copy operation, and thus the description thereof is omitted.

  When the ECS process 124 receives the return value of the resource acquisition function of the scanner engine, the thread 7 sends a scanner parameter confirmation request message to the FCS process 127 (step S1107). Here, the scanner parameters are, for example, fine and normal scan densities, document sizes, and the like. When the FCS process 127 receives this scanner parameter confirmation request message, the thread 4 transmits the scanner parameter as a message to the ECS process 124 (step S1108).

  In the ECS process 124, the server dispatcher receives the scanner parameter message and notifies the thread 7 that has transmitted the scan parameter confirmation request message, 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 generates and executes a scan / feed-in process by the thread 11 (step S1110).

  Next, a document feed-in start message is transmitted to the FCUH process 129 (step S1111). The FCUH process 129 receives a feed-in start message and starts document feed-in, whereby document scanning and transmission to a designated destination are started.

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

  The ECS process 124 transmits the received scan end message to the FCS process 127 together with the presence of the next page document (step S1114). On the other hand, when the document scan is completed, the SRM process 123 instructs the FCUH process 129 to end the feed-in (step S1115), thereby completing the document feed-in.

  When the fax application process 113 makes a transmission mode change request function call to the FCS process 127 (step S1105), the ECS process 124 sends a scan parameter confirmation request message to the FCS process 127 in the thread 6. In response to this, as described above, the FCS process 127 transmits a scan parameter message to the ECS process 124 (step S1118). Upon receiving the scan parameter message, the ECS process 124 instructs the SRM process 123 to execute the scan / feed-in process for the next page and starts the execution (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 an EOM message (with the next page in a different transmission mode) to the FCUH process 129 in the thread 5 (step S1121) and receives this. The FCUH process 129 transmits the EOM to the designated destination by the thread 13 (step S1122).

  When the FCUH process 129 receives a normal reception notification from the designated destination (step S1123), it transmits a transmission success message to the SRM process 123 (step S1124), and the SRM process 123 that has received the message transmits the ECS process 124. A process normal end message is transmitted to (step S1125). 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 S1126). Then, the SRM process 123 that has received the successful transmission message instructs the scanner engine to transmit a stamp such as the transmission date and time and the transmission source to the designated destination according to the instruction (step S1127).

  The SRM process 123 transmits a document feed-in start message to the FCUH process 129 in order to start the document feed-in for the second page (step S1128). The FCUH process 129 receives a feed-in start message and starts document feed-in, whereby scanning of the document on the second page and transmission to a designated destination is started.

  When scanning of a document is started, a next page document presence / absence notification message is transmitted from the scanner engine to the ECS process. In the example of FIG. 11, a next page document presence / absence notification message is notified and is sent to the thread 9 of the ECS process 124. Notification is made (step S1129). When scanning of the document is completed, a scan end message is transmitted from the scanner engine to the ECS process 124 (step S1130).

  The thread 9 of the ECS process 124 transmits the received scan end message to the FCS process 127 together with the fact that there is no next page document (step S1131). On the other hand, when the scanning is completed, in the SRM process 123, the thread 13 instructs the FCUH process 129 to end the feed-in (step S1132), thereby completing the document feed-in.

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

  When the FCUH process 129 receives a normal reception notification from the designated destination (step S1135), the thread 13 transmits a transmission success message to the SRM process 123 (step S1136). The thread 12 transmits a process normal end message to the ECS process 124 (step S1137).

  Further, the ECS process 124 that has received this transmits a scan processing completion notification message for the second page to the FCS process 127 by the thread 9 (step S1138). In addition, the SRM process 123 that has received the successful transmission 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).

  Then, the ECS process 124 transmits a job end notification message to the FCS process 127 (step S1140), and the FCS process 127 receives the job end notification message by the client dispatcher, thereby completing the fax transmission operation for all documents. To do.

  As described above, in the MFP according to the first embodiment, a client process such as each application process requests a service by a function call to a process such as an ECS process, an MCS process, and an SRM process, and a message. Communication between processes can be realized by transmitting and receiving. For this reason, in a multifunction peripheral having a special configuration of the application 130 and the platform 120, a wide variety of functions called complex services can be realized.

  Further, in the multi function device of the first embodiment, the function return value as a result of the service request by the function call is monitored and received by the client dispatcher, so that the synchronous control between the threads in the process can be easily performed. . For this reason, even if there is a change in only some modules of the application process or multiple control services, it is not necessary to change the interface with other processes if the function call and control of the function return value are designed securely. Therefore, it is possible to easily cope with a function change for each application and each control service, and it is possible to make the configuration of the multifunction device variable.

Further, in the multi-function device of the first embodiment, while performing parallel execution by threads, synchronous control between threads in interprocess communication is performed by controlling function calls having affinity to threads and control of their function return values. The overhead at the time of switching the parallel processing can be reduced as much as possible to improve the processing speed when providing the composite service.
(Embodiment 2)
In the MFP 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. Note that the configuration of the MFP 100 according to the second embodiment is the same as that in FIG.

  FIG. 13 is a block diagram illustrating in detail the relationship between a server process and a client process that operate on the multifunction peripheral 100 according to the second embodiment. Here, the client process 1600 refers to a process such as the SCS 122 that receives a service from the server processes 1610 and 1620 by making a request to the server processes 1610 and 1620. The server processes 1610 and 1620 are processes such as ECS 124 that provide services to the client process 1600 in response to a request from the client process 1600.

  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, a service can be requested to a plurality of server processes 1610 and 1620 at the same time.

  Further, the client process 1600 performs a function call from the thread 1601 to the server processes 1610 and 1620 in order to request the services of the server processes 1610 and 1620, and performs inter-process communication by receiving the function return values. .

  The thread 1601 of the client process 1600 calls a function provided from the server processes 1610 and 1620 in advance. The function is defined in the client stub 1602. The client dispatcher 1603 is a thread that monitors reception of a function return value.

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

  For example, the server dispatcher 1611 of the server process 1610 selects a thread 1613 corresponding to the requested function from a plurality of threads 1613 coded in the server skeleton 1612. 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 processing and transmits the execution result to the client process 1600 as a function return value.

  Next, a generation method for generating the client process 1600 and the server processes 1610 and 1620 according to the second embodiment will be described. FIG. 14 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. 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 generates an header from an input unit 1702 that inputs a message file 1701, a syntax analysis unit 1703 that checks the syntax of the contents described in the message file 1701, and the description contents of the message file 1701. 1706, a client stub 1707, and a code generator 1704 that generates a server skeleton 1705 and stores it 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, the client stub 1707, and the server skeleton 1705 will be described.

  A message file 1701 is a source file in which communication contents of inter-process communication are described in a source code such as C language. FIG. 15 is an explanatory diagram of a description example of a message file. As shown in FIG. 15, the message file 1701 includes another message file, an include declaration for declaring an include header of a C language description, a message description describing a message transmitted and received between the server process and the client process, The declaration of the function issued from the client process to the server process is described.

A message is issued mainly when an event or notification is performed between a server process and a client process. As a message description of the message file 1701, a message name, a message ID, a message direction, and a message content are described. It is supposed to be.

  The message direction includes “IN”, “OUT”, and “SELF”. “IN” means a message transmitted from the client process to the server process. “OUT” means a message transmitted from the server process to the client process. “SELF” means a message to be transmitted to its own process.

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

  The client stub 1707 is a source file describing the issuance of a function called from the client program to the server process. By compiling the client stub 1707 into a library and linking with the client program, a 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 a client stub 1707 generated by the stub generator. As shown in FIG. 16, a function call is performed on the client stub 1707 by calling a function handler registered in a server skeleton 1705 described later. The server skeleton 1705 is a source file in which a function handler called from the client stub 1707 and a 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, function handlers corresponding to the functions described in the client stub 1707 are registered in the server skeleton 1705.

  In the function handler, only the argument passing part is described, and the implementation description part describing the processing contents is generated in a blank state. In this implementation description section, 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. The header 1706 is a source file describing definitions and declarations common to the server skeleton 1705 and the client stub 1707.

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

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

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

  If there is a syntax error in the description of the function declaration, message definition, or include declaration, or if any of the function name, message ID, or message name is duplicated, a message to the user that it is a syntax error And the process ends (steps S1803 and S1804).

  After the syntax analysis, the code generation unit 1704 generates a header 1706, a server skeleton 1705, and a client stub 1707 from the description content of the message file 1701. Specifically, the include declaration and C language description of the message file 1701 are transferred as they are to the header 1706, and the message structure described in the message definition of the message file 1701 is copied to the header 1706 (step S1805).

  In addition, the code generation unit 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 the server skeleton. Register in 1705.

  In the function handler process, argument passing is described and issue of a return value area generation system call is described. The field of the implementation description part describing the actual processing contents of the function handler is left blank, and after the implementation description part, the issue of each system call for return value transmission and return value area release is described (step S1806).

  In addition, the code generation unit 1704 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 and the function handler are included in the processing of the function. Each system call for calling and return value release is described (step S1807). A function return value waiting system call that waits for a return value of the issued function is internally issued for the function handler call.

  When the client stub 1707, the server skeleton 1705, and the header 1706 are generated by the stub generator in this manner, the server object and the client object are then completed.

  The developer of the server program describes the processing contents to be performed by the function handler in the function handler implementation description section (blank) of the server skeleton 1705 using an editor or the like, and compiles the server skeleton 1705 together with the header 1706 to Create a stub object. In addition, a function handler registered in the server skeleton 1705 is declared, a message handler that transmits / receives a message described in the message file 1701 to / from a client process, an error handler that performs error processing, server initialization, a server dispatcher Create and compile a server source file that describes the issuance of system calls such as startup, and link 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 generated for each server process, and the plurality of generated client stub objects are used as a library.

  Also, function issuance, function handler declaration, error handler declaration for error handling, message handler for sending and receiving messages described in the message file 1701 with the client process, and initialization of the client process and client dispatcher A client program describing the issuance of system calls such as activation is created and compiled, and the client program is completed by linking with a stub library.

  FIG. 20 is an explanatory diagram showing a calling and response sequence with the server program when a function call is made from the client program. The server program and the client program are actually executable object files, but in FIG. 20, both are displayed in source code for convenience of explanation.

  For example, 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 stub Open process, the Open function handler Open_handler is called to the server program (step S1902).

  The server program receives the issuance of the function handler Open_handler from the client stub object, executes the process described in the implementation description part of the Open_handler registered in the server stub object (step S1903), and outputs the execution result to the client stub. Is returned as a return value (step S1904). The client program receives this return value from the client stub (step S1905), and proceeds to the next processing.

  As described above, the stub generator of 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. In addition, 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 necessary.

  For this reason, the multifunction device 100 can be provided with variability and various functions can be realized. In addition, even when a third-party vendor or other company develops a client program, inter-process communication is possible simply by describing the function call provided in the client program, so the internal communication protocol is concealed. Is possible.

In the stub generator of the second embodiment, since inter-process communication is realized by function calls, high-speed inter-process communication is possible even when parallel execution of jobs is realized by threads. Further, 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 for program development can be reduced.
(Embodiment 3)
In the MFP 100 according to the first embodiment, an application process that is a client process operates in the same MFP as each control service that is a server process. In the MFP 100 according to the third embodiment, each control service provides a service using an application process of another MFP connected to a network as a client process.

  FIG. 21 is a block diagram of the configuration of the multifunction machine according to the third embodiment. As shown in FIG. 21, the third embodiment has a configuration in which a plurality of multifunction peripherals 1300a and 1300b are connected by a network 1340 such as a LAN. In FIG. 21, two MFPs 1300a and 1300b are connected via a network 1340. However, a configuration in which three or more MFPs are connected via a network 1340 may be used.

  As shown in FIG. 21, each multifunction device 1300a, 1300b on the network 1340 has the same configuration as the multifunction device of the first embodiment. For this reason, detailed description about these structures is abbreviate | omitted.

  In the MFP of the third embodiment, as in the first embodiment, application processes such as the copy application 1312, the printer application 1311, the scanner application 1314, and the fax application 1313, and the control of the ECS 1324, the MCS 1325, the FCS 1327, the NCS 1328, and the like. The service process is a control process or a client process using the SRM 1323 as a server process. In addition, a control process such as ECS 1324, MCS 1325, FCS 1327, NCS 1328, etc. operating inside another multifunction peripheral connected to the network is used as the server process. Client process.

  In the MFP of the third embodiment, as in the first embodiment, the control service such as ECS1324, MCS1325, FCS1327, and NCS1328 and the SRM1323 process are mainly the application process or the control service or the SRM1323 process as the client process. The server process uses a client process that is an application process such as a copy application 1312, a printer application 1311, a scanner application 1314, or a fax application 1313 operating in another multifunction peripheral connected to the network. It also becomes a process.

  The relationship between the server process and the client process and the configuration of the server process and the client process in the multifunction device of the third embodiment are the same as those in FIGS. 2 and 3 described in the multifunction device of the first embodiment. Is omitted.

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

  In the MFPs 1300a and 1300b according to the third embodiment, a client process such as an application makes a function call to a server process from a thread in the client process in order to request a service of a server process such as a control service. Receive inter-process communication by receiving the function return value and sending a message from the thread to the server process. Furthermore, function calls and messages can be sent to server processes operating on other multifunction devices on the network.

  On the other hand, in a server process such as a control service, interprocess communication with a client process is performed only by sending a message. Further, in the server process, it is possible to send a message to a client process on the network by using a process operating on another multifunction device on the network as a client process.

  The client dispatcher activated by the client process has the same configuration as that of the MFP 100 of the first embodiment, and also receives function return values and OUT direction messages from other MFPs connected to the network 1340. Monitoring.

  For this reason, the function format and message format issued from the client process are provided in a format that can specify information such as the network address so that inter-process communication can be performed with other multifunction devices on the network. .

  The server dispatcher activated by the server process has the same configuration as that of the server process in the multi-function device 100 of the first embodiment, but further from the thread of the client process operating in another multi-function device connected to the network 1340. The function calls and messages in the IN direction are also monitored.

  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. It can be specified. The message sent from the server process can also specify a network address.

  Next, inter-process communication in the case of performing a printing operation using different multifunction machines on the network 1340 in the multifunction machines 1300a and 1300b according to the third embodiment configured as described above will be described. FIG. 22 is an explanatory diagram illustrating a data sequence between processes of the printer application and the ECS when a printer operation is performed using 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 with reference to FIG. 5 in the first embodiment, the thread of the printer application process 1311 of the multi-function peripheral 1300a sends the thread to the ECS process 1324. A job operation mode setting function call and a job start request function call are sequentially performed.

  In the third embodiment, at this time, the printer application process 1311 of the multifunction device 1300a designates the network address of another multifunction device 1300b connected via the network 1340, and the job operation mode setting function call and the job start request function A call is made (steps S1402 and S1404).

  As a result, the job operation mode setting function call and the job start request function call are transmitted to the ECS process 1324 of the MFP 1300b designated by the network address instead of the ECS process 1324 of the MFP 1300a. Then, the thread that made each function call waits for a function return.

  In the ECS process 1324 of the MFP 1300b, the server dispatcher receives a job operation mode setting function call and a job start request function call via the network 1340, and sets the printer job operation mode and printer job start processing by each function handler. I do. 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 multifunction device 1300a, 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 multifunction device 1300b are received by the client dispatcher. Then, as in the case of the MFP of the first embodiment, the function return waiting state thread 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.

  The subsequent inter-process communication with the ECS process 1324, the MCS process 1325, and the SRM process 123 is performed inside the same multifunction peripheral, and is the same as the printer operation described in the first embodiment. Thus, in response to a print request in the multifunction device 1300a, the actual print processing is performed in the multifunction device 1300b.

  When the print processing in the multifunction device 1300b is completed, the ECS process 1324 of the multifunction device 1300b transmits a job end notification message to the printer application process. At this time, the server dispatcher of the ECS process 1324 designates the network address of the MFP 1300a on the network 1340 and transmits a job end notification message (step S1406).

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

  As described above, in the third embodiment, inter-process communication is performed between the application process that operates in the multifunction device 1300a connected to the network and the ECS process 1324 that operates in the multifunction device 1300b, and is generated in the multifunction device 1300a. In response to the request, the other multifunction device 1300b on the network 1340 can perform print processing, so that various functions can be realized using not only the requested multifunction device but also the multifunction device on the network.

  For example, when a print request is generated in the multifunction device 1300a, if the printer engine of the multifunction device 1300a is occupied by another job, the printer application process determines this and makes a function call to the ECS process 1324 in the network. If processing such as switching to a function call to the ECS process 1324 of another multifunction device 1300b on 1340 is performed, it is possible to prevent time from starting printing and 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 giving an example of the printer operation. However, in the scanner operation, the copy operation, and the facsimile transmission operation, the complex operation is performed. Inter-process communication between the scanner application process 1314, the copy application process 1312, the fax application process 1313, and the ECS process 1324 in the apparatus 1300a is performed in the same manner as in the case of the printer operation.

  In the MFPs 1300a and 1300b according to the third embodiment, the interprocess communication via the application process, the ECS process 1324, and the network 1340 has been described. However, control services other than the application process and the ECS process 1324 and the system resource manager (SRM) ) The inter-process communication 1323 is performed in the same manner as the communication between the application process and the ECS process 1324.

  Further, in the MFPs 1300a and 1300b according to the third embodiment, the application process and the ECS process 1324 in another MFP on the network 1340 directly perform inter-process communication, but the applications of different MFPs via the NCS 1328. The process and the ECS process 1324 may be configured to communicate with each other.

  That is, the NCS 1328 temporarily receives a function call or message from the application process, designates the network address of another multifunction device 1300b on the network 1340, and then sends the function call or message to the NCS process 1328 of the multifunction device 1300b. It can also be configured to transmit.

In this case, in the application process and the ECS process 1324, it is not necessary to add processing related to the network address, and the independence between the modules is further increased. Therefore, there is an advantage that variability can be provided by the multifunction peripheral.
(Embodiment 4)
In the MFPs 1300a and 1300b according to the third embodiment, each control service provides a service using an application process of another MFP connected to the network 1340 as a client process. In the MFP according to the fourth embodiment, each control service provides a service using the control service of another MFP connected to the network as a client process.

  In the fourth embodiment, similarly to the multifunction machines 1300a and 1300b of the third embodiment shown in FIG. 21, a plurality of multifunction machines are connected by a network 1340 such as a LAN. Since each multifunction device 1300a, 1300b on the network 1340 in the fourth embodiment has the same configuration as the multifunction device in the first embodiment, detailed description of these configurations is omitted.

  In the MFP of the fourth embodiment, as in the first embodiment, application processes such as a copy application 1312, a printer application 1311, a scanner application 1314, and a fax application 1313, and control services such as an ECS 1324, MCS1325, FCS1327, and NCS1328 are mainly used. Is a client process using the control service or SRM 1323 as a server process, and further, a control service such as ECS 1324, MCS 1325, FCS 1327, and NCS 1328 operating inside another multifunction peripheral connected to the network is referred to as a server process. Client process.

  In the MFP of the fourth embodiment, as in the first embodiment, the control service such as ECS 1324, MCS 1325, FCS 1327, and NCS 1328 and the process of SRM 1323 are mainly the application service or control service or SRM 1323 as a client process. It is also a server process that uses a control service operating inside another multifunction peripheral connected to the network as a client process.

  The relationship between the server process and the client process in the MFPs 1300a and 1300b according to the fourth embodiment, and the configurations of the server process and the client process are described with reference to FIGS. 3 is the same as in FIG.

  In the MFPs 1300a and 1300b according to the fourth embodiment, when the control service is a client process, a function from a thread in the client process is requested to the server process in order to request a service of a server process such as another control service. Interprocess communication is performed by making a call, receiving the function return value, and sending a message from the thread to the server process. Furthermore, function calls and messages can be transmitted to other control services operating on other multifunction devices on the network 1340 or server processes such as SRM 1323.

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

  For this reason, the function format and message format issued from the client process are provided in such a format that information such as a network address can be specified so that inter-process communication can be performed with other MFP processes on the network 1340. The

  The server dispatcher activated by the server process is similar to the server process in the multifunction peripherals 1300a and 1300b of the third embodiment, and the function call and IN from the thread of the client process operating in another multifunction peripheral connected to the network 1340 Direction messages are also monitored.

  Also in the fourth embodiment, in the control service such as ECS 1324, MCS 1325, FCS 1327, NCS 1328 and SRM 1323 which are server processes and client processes, the function handler executed when the function call is received by the server dispatcher is the client that made the function call. You can specify the network address of the multifunction device where the process exists. The message sent from the server process can also specify a network address.

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

  When the FCS process 1327 receives a transmission start request from the fax application process 1313 (step S1501), the thread of the FCS process 1327 of the MFP 1300a specifies the network address of another MFP 1300b connected to the network 1340. Then, the job operation mode setting function call and the job start request function call are sequentially performed (steps S1502 and S1504).

  As a result, the job operation mode setting function call and the job start request function call are transmitted via the network to the ECS process 1324 operating on the multifunction peripheral 1300b specified by the network address.

  In the ECS process 1324 of the MFP 1300b, the server dispatcher receives a job operation mode setting function call and a job start request function call via the network 1340, and sets the printer job operation mode and printer job start processing by each function handler. I do. 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 MFP 1300a (steps S1503 and S1505).

  In the FCS process 1327 of the MFP 1300a, 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 MFP 1300b are received by the client dispatcher. Then, as in the case of the MFP of the first embodiment, the function return waiting state thread 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.

  The ECS process 1324 of the MFP 1300b makes a memory allocation request function call to the MCS process 1325 (step S1505), and makes a scanner engine resource acquisition request function call to the SRM process 123 (step S1506). The processing of the MCS process 1325 and the SRM process 1323 for such a function call is as described in the first embodiment.

  When the ECS process 1324 of the MFP 1300b receives the return value of the scanner engine resource acquisition function, it sends a scan parameter request message specifying the network address of the MFP 1300a to the FCS process 1327 of the MFP 1300a via the network. (Step S1507).

  When the FCS process 1327 of the MFP 1300a receives this scanner parameter confirmation request message, the scanner parameter message is sent to the ECS process 1324 of the MFP 1300b via the network by designating the network address of the MFP 1300b. (Step S1508). In the ECS process 1324, the server dispatcher receives the scanner parameter message over the network.

  The subsequent inter-process communication is performed within the same multifunction device 1300b, and is the same as the facsimile transmission described in the first embodiment. Thus, in response to a facsimile transmission start request in the multifunction device 1300a, the multifunction device 1300b performs facsimile transmission. When the scanning and facsimile transmission processing in the multifunction device 1300b is completed, the server dispatcher of the ECS process 1324 of the multifunction device 1300b designates the network address of the multifunction device 1300a on the network 1340 and sends a scan end notification message to the FCS process of the multifunction device 1300a. It transmits to 1327 (step S1509).

  In the FCS process 1327 of the MFP 1300a, 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 MFP according to the fourth embodiment, inter-process communication is performed between the FCS process 1327 operating on the MFP 1300a connected to the network and the ECS process 1324 operating on the MFP 1300b. Since a facsimile transmission process can be performed by another multifunction device 1300b on the network 1340 in response to a request generated by the device 1300a, various functions can be realized by using not only the requested multifunction device but also the multifunction device on the network 1340. can do.

  For example, when a facsimile transmission request is generated in the multifunction device 1300a, if the facsimile engine of the multifunction device 1300a is occupied by a facsimile reception job, the FCS process 1327 determines this and makes a function call to the ECS process 1324. If processing such as switching to a function call to the ECS process 1324 of another multifunction device 1300b on the network 1340 is performed, facsimile transmission can be performed immediately, and usability of the multifunction device can be improved.

  In the fourth embodiment, the inter-process communication in the two multifunction devices 1300a and 1300b connected to the network 1340 has been described by giving an example of the facsimile transmission operation. However, in the scanner operation, the copy operation, and the print operation, the complex operation is also performed. The inter-process communication between the control service in the machine 1300a and the control service in the multifunction machine 1300b is performed in the same manner.

  In the MFP according to the fourth embodiment, the interprocess communication between the FCS process 1327 and the ECS process 1324 via the network 1340 has been described. This is performed in the same manner as the communication between the process 1327 and the ECS process 1324.

  Further, in the MFP of the fourth embodiment, the FCS application process 1327 and the ECS process 1324 in another MFP on the network 1340 perform direct interprocess communication. In this case as well, the NCS process 1328 is used. You may comprise so that communication between the control services of a different multifunction device may be performed.

  As described above, the functions and messages used in the MFPs of Embodiments 1 to 4 are all examples, and are not particularly limited to these, and arbitrary functions and messages can be defined and used.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

1 is a block diagram illustrating a configuration of an image forming apparatus (multifunction machine) according to an embodiment of the present invention. 3 is a block diagram illustrating a relationship between a server process and a client process in the multifunction machine according to the first embodiment. FIG. FIG. 3 is a block diagram illustrating a configuration of a client process that operates on the multifunction peripheral according to the first embodiment. 3 is a block diagram illustrating a configuration of a server process that operates in the multifunction peripheral according to the first embodiment. FIG. FIG. 6 is an explanatory diagram illustrating a data sequence between processes of an application, a control service, and a system resource service when a printer operation is performed in the multifunction peripheral according to the first embodiment. FIG. 6 is an explanatory diagram illustrating a function and a message transmission / reception relationship between processes of an application, a control service, and a system resource service when a printer operation is performed in the multifunction peripheral according to the first embodiment. 6 is an explanatory diagram illustrating a data sequence between processes of an application, a control service, and a system resource service when a scanner operation is performed in the multifunction peripheral according to the first embodiment. FIG. FIG. 6 is an explanatory diagram illustrating a function and a message transmission / reception relationship between processes of an application, a control service, and a system resource service when a scanner operation is performed in the multifunction peripheral according to the first embodiment. 6 is an explanatory diagram illustrating a data sequence between processes of an application, a control service, and a system resource service when a copying operation is performed in the multifunction peripheral according to the first embodiment. FIG. FIG. 6 is an explanatory diagram illustrating a relationship between a function and a message transmission / reception among processes of an application, a control service, and a system resource service when a copying operation is performed in the multifunction peripheral according to the first embodiment. 6 is an explanatory diagram illustrating a data sequence between processes of an application, a control service, and a system resource service when a facsimile transmission operation is performed in the multifunction machine according to the first embodiment. FIG. FIG. 6 is an explanatory diagram illustrating functions and message transmission / reception relationships between processes of an application, a control service, and a system resource service when a facsimile transmission operation is performed in the multifunction peripheral according to the first embodiment. 6 is a block diagram illustrating in detail a relationship between a server process and a client process operating on the multifunction peripheral 100 according to the second embodiment. FIG. 10 is a block diagram illustrating a functional configuration of a communication program generation apparatus (stub generator) for an image forming apparatus that generates a client process and a server process according to Embodiment 2. FIG. It is explanatory drawing which shows the example of a description of a message file. It is explanatory drawing which shows an example of the client stub produced | generated by the stub generator. It is explanatory drawing which shows an example of the server skeleton produced | generated by a stub generator. It is explanatory drawing which shows an example of the header produced | generated by a stub generator. It is a flowchart of a production | generation process of a server skeleton, a client stub, and a header. It is explanatory drawing which shows the sequence of a call and a response with a server program when a function call is performed from a client program. 3 is a block diagram illustrating a configuration of a multifunction machine according to a second embodiment; FIG. FIG. 10 is an explanatory diagram showing a data sequence between a printer application and an ECS process when a printer operation is performed using two multifunction peripherals connected to the network according to the second embodiment. FIG. 10 is an explanatory diagram illustrating a data sequence between FCS, ECS, and MCS processes when a facsimile transmission operation is performed using two multifunction peripherals connected to the network according to the third embodiment.

Explanation of symbols

100, 1300a, 1300b MFP 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 application 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 Application 201, 1600 Client process 202, 1610, 1620 Server process 203, 1603 Client dispatcher 204, 1611 Server dispatcher 1601, 1613, 1623 Thread 1602 Client stub 1612, 1622 Server skeleton

Claims (17)

An information processing apparatus having one or more programs for performing information processing,
Each of the programs is a process including one or more threads operating as a server process or a client process,
The server process thread has a function that defines one or more services to be provided to the client process thread;
The information processing apparatus according to claim 1, wherein the thread of the client process calls a function when requesting provision of a service to the thread of the server process.   2. The program according to claim 1, further comprising client monitoring means for receiving a function return value for a function call to the server process and delivering the received function return value to a thread that has made the function call. Information processing device.   The information processing apparatus according to claim 2, wherein the client monitoring unit is realized by a thread.   The client monitoring means further includes a function return waiting queue for temporarily storing an identifier of a thread waiting for a function return value after the function is called, and the function received when the function return value is received from the server process. 4. The information processing apparatus according to claim 2, wherein a return value is transmitted to the thread having the identifier stored in the function return waiting queue.   The information processing apparatus according to claim 2, wherein the server process and the client process further perform any one of transmission, reception, and transmission / reception of a message related to an event or a notification.   6. The information processing apparatus according to claim 5, wherein the client monitoring unit further monitors reception of a message from a server process.   The information processing apparatus according to claim 6, wherein the client monitoring unit further includes a message handler that executes processing based on the received message. The server process, the information processing apparatus of any one of claims 1 to 7, characterized in that it comprises a server monitoring means for monitoring the function call from the client process.   The information processing apparatus according to claim 8, wherein the server monitoring unit monitors function calls from a plurality of client processes.   The information processing apparatus according to claim 8, wherein the server monitoring unit includes a function handler that executes a process corresponding to the called function when a function call is received from the client process.   The information processing apparatus according to claim 8, wherein the server monitoring unit further monitors reception of a message from the client process.   The information processing apparatus according to claim 11, wherein the server monitoring unit further includes a message handler that executes processing based on a message received from the client process. An information processing apparatus having one or more programs for performing information processing,
Each of the programs is a process including one or more threads operating as a server process or a client process,
The server process operates as a server process for a client process that operates on another information processing apparatus connected to a network, and provides one or a plurality of server processes as a thread of a server process to a thread of a client process of the other information processing apparatus An information processing apparatus having a function that defines a service.   The information processing apparatus according to claim 13, wherein the one or more threads included in the server process execute a service provided to a thread of a client process of the other information processing apparatus.   15. The information processing apparatus according to claim 13, wherein the server process includes server monitoring means for monitoring a function call from a client process of the other information processing apparatus.   The information processing apparatus according to claim 15, wherein the server monitoring unit further monitors reception of a message from a client process of the other information processing apparatus.   The information processing apparatus according to claim 13, wherein the server process further transmits a message to a client process of the other information processing apparatus.

Images