EP0940750B1 - Datenverarbeitungsverfahren - Google Patents

Datenverarbeitungsverfahren Download PDF

Info

Publication number
EP0940750B1
EP0940750B1 EP99301646A EP99301646A EP0940750B1 EP 0940750 B1 EP0940750 B1 EP 0940750B1 EP 99301646 A EP99301646 A EP 99301646A EP 99301646 A EP99301646 A EP 99301646A EP 0940750 B1 EP0940750 B1 EP 0940750B1
Authority
EP
European Patent Office
Prior art keywords
processing
data area
server
data
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
EP99301646A
Other languages
English (en)
French (fr)
Other versions
EP0940750A2 (de
EP0940750A3 (de
Inventor
Koichi c/o Sony Corporation Moriyama
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of EP0940750A2 publication Critical patent/EP0940750A2/de
Publication of EP0940750A3 publication Critical patent/EP0940750A3/de
Application granted granted Critical
Publication of EP0940750B1 publication Critical patent/EP0940750B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Definitions

  • the present invention relates to a data processing method employed when messages are exchanged between objects.
  • the invention also relates to a recording medium on which an operating system implementing the above data processing method is recorded, and to a data processing apparatus provided with the above recording medium.
  • a message sending object is shown as a client object, while a message receiving object is shown as a server object.
  • the client object continues processing, as indicated by the solid line B4 in Fig. 1, after sending the above message to the server object. Thereafter, when the client object requires the result of the processing performed by the server object, it reads the data stored in the future, as represented by the arrow B5 in Fig. 1.
  • the client object immediately receives the processing result. If, however, the result of the processing performed by the server object has not yet been stored in the future, the client object remains in the waiting state before the result is stored in the future.
  • an operating system providing a function of future-based message passing be able to resume processing of an object even when the object enters the waiting state due to some problem, so that software running on the operating system is stably operated.
  • time-out processing is often executed regardless of the reason of the occurrence of a waiting-state in order to discontinue the above state.
  • the waiting state continues until the time-out processing is started, thereby wasting time depending on the period set for starting the time-out processing. Additionally, even if the waiting state is discontinued by the time-out processing, the reason for the occurrence of the waiting state cannot be specified, which may further cause the occurrence of another waiting state.
  • an object of the present invention to provide a data processing method in which even if an object enters a waiting state due to some problem with the server, or communication channels on the server side, while future-based message passing is being performed, the object can exit from the waiting state without needing to execute time-out processing.
  • the operating system recorded on the recording medium provided with the data processing apparatus stores the provided with the data processing apparatus stores the status data of the server object in the above-described data area if the processing executed by the server object has not been correctly completed. Accordingly, by reading the data stored in the data area, the client object is able to receive the status data. Thus, even if the client object enters the waiting state due to some problem while message passing is being performed, the status of the server object can be informed to the client object without needing to execute time-out processing, thereby enabling the client object to exit from the waiting state.
  • FIG. 2 An example of a data processing apparatus incorporating the present invention is first described with reference to Fig. 2.
  • a television set loaded with a data processing function incorporating the present invention is described.
  • the present invention is applicable to other types of data processing apparatuses. That is, the present invention is widely used in data processing apparatuses on which an operating system runs, for example, audio-visual machines (what is called, "AV machines") other than the television set, office machines, and ordinary computers.
  • AV machines audio-visual machines
  • the television set shown in Fig. 2 which serves as the data processing apparatus incorporating the present invention, receives a signal from a broadcast station via an antenna or a cable (neither of them is shown), and based on the signal, displays an image on an image display unit, such as a cathode ray tube or a liquid crystal panel, and also outputs sound from a speaker.
  • an image display unit such as a cathode ray tube or a liquid crystal panel
  • the television set is not only provided with an ordinary television function, but is also able to receive programs and data from an external source.
  • the television set is formed of, as illustrated in Fig. 2, a television function unit 3 connected to a bus 2 via a bus/input output (IO) bridge 1, a processor 5 connected to the bus 2 via a bus/memory bridge 4, a read only memory (ROM) 6 and a random access memory (RAM) 7 connected to the processor 5 via the bus/memory bridge 4, and an operation panel 8, an external storage device 9, a communication unit 10, and a graphics device 11, all of which are connected to the bus 2.
  • IO bus/input output
  • ROM read only memory
  • RAM random access memory
  • the television function unit 3 serves the function of reproducing images and sounds based on a signal received by the antenna or the cable (neither of them is shown).
  • the television function unit 3 is connected to the bus 2 via the bus/IO bridge 1 so that it can transmit or receive signals to or from the other elements.
  • the ROM 6 and the RAM 7 are connected to the processor 5 via the bus/memory bridge 4.
  • the ROM 6 stores an operating system and application programs used for the control performed by the processor 5.
  • the operating system stored in the ROM 6 is an object-oriented operating system implementing object orientation.
  • the RAM 7 is used as a work area for the processor 5. More specifically, the processor 5 runs the operating system and the application programs stored in the ROM 6 by using the RAM 7 as a work area, thereby controlling the individual elements of the television set.
  • the operation panel 8 is an input unit for receiving the operation which is input by the user, and a signal indicating an instruction for, for example, the switching of the channel or the volume control of the television set, is input from this operation panel 8. More specifically, the operation panel 8 is formed of an input unit provided with a plurality of buttons for inputting various signals and a pointing device, i.e., a mouse.
  • the signal input through the operation panel 8 is input into the processor 5 via the bus 2 and the bus/memory bridge 4.
  • the processor 5 then executes predetermined computational processing based on the signal input through the operation panel 8, thereby controlling the individual elements.
  • the external storage device 9 which is formed of, for example, a hard disk drive unit, is used for recording data, such as images and sounds, control data required for controlling the television set, application programs externally downloaded via the communication unit 10, etc.
  • the communication unit 10 which is an input/output unit for performing data communications with an external source, is formed of a modem, a terminal adapter, etc.
  • the graphics device 11 processes data recorded on the external storage device 9 and data received from an external source via the communication unit 10, and displays the corresponding images.
  • the television set not only includes an ordinary television function provided by the television function unit 3, but also receives data from an external source via the communication unit 10. More specifically, the television set is able to receive, for example, a new software module from an external network via the communication unit 10, thereby upgrading the version of the operating system and the application programs.
  • the processor 5 runs the operating system stored in the ROM 6, and also executes the application programs stored in the ROM 6 and in the external storage device 9 on the operating system, thereby controlling the individual elements of the television set. That is, the television set is provided with the ROM 6, which serves as a computer-readable recording medium on which the operating system is recorded.
  • the operating system may be stored in the RAM 7 or the external storage device 9, particularly when it is desired that the operating system be overwritten.
  • the operating system used in the aforementioned television set is an object-oriented operating system.
  • software such as an application program, running on the operating system is formed into modules as objects, and object interaction is conducted by message passing.
  • This operating system has a micro-kernel, as shown in Fig. 3, that provides the basic function as the operating system, thereby making it possible to simultaneously provide a plurality of program execution environments on the micro-kernel.
  • the program execution environment provided by the operating system is referred to as a "metaSpace”.
  • the operating system provides, as a metaSpace, an mCOOP metaSpace constructed by a plurality of objects, and an mDrive metaSpace constructed by a plurality of objects.
  • An application program interface (hereinafter referred to as an "API") used for describing objects of an application program is assigned to each metaSpace.
  • an object used in a metaSpace is referred to as a "metaObject”.
  • the mCOOP metaSpace is a metaSpace primarily for operating an object-oriented application program (for example, an application program for implementing a graphical user interface for controlling the operation panel 8).
  • the "m” in mCOOP metaSpace represents a metaSpace, and "COOP” stands for Concurrent Object Oriented Programming.
  • the mDrive metaSpace is a metaSpace for operating a device driver (for example, a device driver for controlling the graphics device 11 or a device driver for controlling the communication unit 10 to transmit and receive data via a network) primarily for controlling hardware.
  • the "m” in mDrive metaSpace designates a metaSpace, and "Drive” represents a metaSpace for operating the device driver (Device Driver).
  • the mCOOP metaSpace and the mDrive metaSpace are operated on the micro-kernel.
  • An application program formed into modules as objects is operated in the mCOOP metaSpace, while a device driver formed into modules as objects is operated in the mDrive metaSpace.
  • This operating system is able to provide not only mCOOP metaSpace and mDrive metaSpace, as the metaSpace operating on the micro-kernel, but also a metaSpace for operating, for example, a procedure-oriented application program (for example, an application program for causing the television function unit 3 to display moving pictures).
  • the metaObject forming mCOOP metaSpace includes, for example, an object "mCOOPMailer” and an object “mCOOPFaultHandler".
  • the object "mCOOPMailer” is a metaObject used for performing message passing between application programs running in the mCOOP metaSpace.
  • the object "mCOOPFaultHandler” is a metaObject for executing exception handling. In practice, the mCOOP metaSpace is formed, not only of the above-described metaObjects, but also of other metaObjects.
  • the metaObject forming mDrive metaSpace includes, for example, an object "mDriveMailer” and an object “mDriveFautlHandler".
  • the object "mDriveMailer” is a metaObject used for performing message passing between device drivers running in the mDrive metaSpace.
  • the object "mDriveFaultHandler” is a metaObject for executing exception handling.
  • the mDrive metaSpace, as well as the mCOOP metaSpace is formed not only of the above-described metaObjects, but also of other metaObjects.
  • This operating system provides the function of future-based message passing, which is discussed in detail below.
  • client object the object that sends a message to another object to request it to execute processing
  • server object the object that receives the message from the client object and executes processing based on the message
  • the aforementioned operating system provides the following methods as the APIs used for describing the objects operating in the mCOOP metaSpace.
  • the API is indicated according to the description method of the Object Management Group Interface Definition Language (OMG IDL).
  • the method "SendWithRBox” is a message-sending method for sending a message from a client object to a server object. That is, the method “SendWithRBox” is employed when it becomes necessary for the client object to obtain the result of the processing executed by the server object after it has sent a message to the server object.
  • the argument "destObjID” is an argument of the "OID” type, which is a data type for specifying the object.
  • the value specifying the server object is set in the argument "destObjID"
  • the argument "meth” is an argument of the "Selector” type, which is a data type for designating the method.
  • the value designating the method of the server object for describing the processing to be requested is set in the argument "meth".
  • the argument "msg” is an argument of the "any” type, which is an arbitrary data type.
  • the pointer to the area for storing the message to be delivered to the server object is set in the argument "msg".
  • sizeOfMsg is an argument of the "size_t” type, which is a data type for specifying the size of the data.
  • sizeOfMsg The value indicating the size of the message to be delivered to the server object is set in the argument "sizeOfMsg".
  • the method "SendWithRBox” After sending the message to the server object, the method "SendWithRBox” obtains the identifier "rBoxID” of the "RID” type, which is a data type for specifying the data area "RBox".
  • the identifier "RBoxID” is an identifier for designating the data area "RBox” reserved by the object "mCOOPMailer” when the method "SendWithRBox” has been issued.
  • the method "SendWithRBox” acquires the value of the "sError” type as the return value, which is a data type representing the error code. That is, if the processing of the "SendWithRBox" is not correctly completed in issuing this method, the error code indicating the error reason is returned as the return value. If the processing is correctly completed, the value indicating that the processing has been correctly completed is returned as the return value.
  • the method "Receive” is a data reading method for reading data stored in the data area "RBox". That is, the method “Receive” is used when the client object receives the result of the processing executed by the server object after it has issued the method "SendWithRBox".
  • the argument "rBoxID” is an argument of the "RID” type, which is a data type for designating the data area "RBox".
  • the identifier for specifying the data area "RBox” which stores the result of the processing performed by the server object is set in the argument "rBoxID”. That is, the value of the identifier "rBoxID” acquired upon issuing the method "SendWithRBox” is set in the argument "rBoxID”.
  • the argument "msg” is an argument of the "any” type, which is an arbitrary data type.
  • the pointer to the area for storing the received message is set in the argument "msg”.
  • sizeOfMsg is an argument of the "size_t” type, which is a data type for specifying the size of the data.
  • sizeOfMsg The value indicating the size of the area for storing the received message is set in the argument "sizeOfMsg".
  • the method "Receive” acquires the value of the "sError” type as the return value, which is a data type representing the error code. That is, if the processing of the "Receive” is not correctly completed in issuing this method, the error code indicating the error reason is returned as the return value. If the processing is correctly completed, the value indicating that the processing has been correctly completed is returned as the return value.
  • the method "Reply” is used when the server object returns the processing result to the client object after the client object has sent the method "SendWithRBox".
  • the argument "resultMsg” is an argument of the "any” type, which is an arbitrary data type.
  • the pointer to the area for storing the message to be sent to the client object is set in the argument "resultMsg”.
  • sizeOfResultMsg is an argument of the "size_t” type, which is a data type for designating the size of the data.
  • sizeOfResultMsg The value indicating the size of the message to be sent to the client object is set in the argument "sizeOfResultMsg".
  • the method "Reply” obtains the value of the "sError” type as the return value, which is a data type representing the error code. That is, if the processing of the "Reply” is not correctly completed in issuing this method, the error code indicating the error reason is returned as the return value. If the processing is correctly completed, the value indicating that the processing has been correctly completed is returned as the return value.
  • the method "Delegate” is an authorization delegating method for delegating an authorization among objects. More specifically, the method “Delegate” is used when the authorization to return the result of the processing executed by the server object to the client object is delegated among a plurality of server objects.
  • the above-mentioned authorization is referred to as the "reply authorization”.
  • the object that delegates the reply authorization is referred to as an "authorization-delegating object”
  • the object that is delegated to receive the reply authorization is referred to as an "authorization-delegated object”.
  • the argument "destObjID" is an argument of the "OID" type, which is a data type for specifying the object.
  • the value representing the authorization-delegated object is set in the argument "destObjID”.
  • the argument "meth” is an argument of the "Selector” type, which is a data type for specifying the method.
  • the value indicating the method of the authorization-delegated object for describing the required processing is set in the argument "meth".
  • the argument "msg” is an argument of the "any” type, which is an arbitrary data type.
  • the pointer to the area for storing the message to be sent to the authorization-delegated object is set in the argument "msg”.
  • sizeOfMsg is an argument of the "size_t” type, which is a data size for designating the size of the data.
  • sizeOfMsg The value representing the size of the message to be sent to the authorization-delegated object is set in the argument "sizeOfMsg".
  • the method "Delegate” obtains the value of the "sError” type as the return value, which is a data type representing the error code. That is, if the processing of the "Delegate” is not correctly completed in issuing this method, the error code indicating the error reason is returned as the return value. If the processing is correctly completed, the value indicating that the processing has been correctly completed is returned as the return value.
  • the aforementioned operating system provides the following methods as the APIs used for describing the objects operating in the mDrive metaSpace.
  • the API is represented in compliance with the OMG IDL.
  • the method "SendWithContinuation” is a message-sending method for sending a message from the client object to the server object.
  • the method “SendWithContinuation” is used when it becomes necessary for the client object to perform a specific method (hereinafter referred to as a “continuation method") upon receiving the processing result of the server object after the client object has sent the message to the server object.
  • the argument "destObjID" is an argument of the "OID" type, which is a data type for specifying the object.
  • the value for specifying the server object is set in the argument "destObjID”.
  • the argument "meth” is an argument of the "Selector” type, which is a data type for designating the method.
  • the value representing the method of the server object for describing the requested processing is set in the argument "meth”.
  • the argument "msg” is an argument of the "any” type, which is an arbitrary data type.
  • the pointer to the area for storing the message to be delivered to the server object is set in the argument "msg".
  • sizeOfMsg is an argument of the "size_t” type, which is a data type for specifying the size of the data.
  • sizeOfMsg The value indicating the size of the message to be delivered to the server object is set in the argument "sizeOfMsg".
  • the argument "contMeth” is an argument of the "Selector” type, which is a data type for designating the method.
  • the value for specifying the continuation method is set in the argument "contMeth”.
  • the data area "Continuation” is an area for storing the continuation method to be executed by the client object, and is referred to as a "future".
  • the method "SendWithContinuation” acquires the value of the "sError” type as the return value, which is a data type representing the error code. That is, if the processing of the "SendWithContinuation" is not correctly completed in issuing this method, the error code indicating the error reason is returned as the return value. If the processing is correctly completed, the value indicating that the processing has been correctly completed is returned as the return value.
  • the method "Kick" is employed when the server object instructs the client object to execute the continuation method after the client object has issued the method "SendWithContinuation”.
  • the argument "contID” is an argument of the "contID” type, which is a data type for designating the data area "Continuation”.
  • the identifier for specifying the data area "Continuation” reserved by the object "mDriveMailer” upon issuing the method "SendWithContinuation” is set in the argument "contID”.
  • the argument "msg” is an argument of the "any” type, which is an arbitrary data type.
  • the pointer to the area for storing the message to be delivered to the client object is set in the argument "msg".
  • sizeOfMsg is an argument of the "size_t” type, which is a data type for specifying the size of the data.
  • sizeOfMsg The value representing the size of the message to be delivered to the client object is set in the argument "sizeOfMsg".
  • the method "Kick” obtains the value of the "sError” type as the return value, which is a data type representing the error code. That is, if the processing of the "Kick" is not correctly completed in issuing this method, the error code indicating the error reason is returned as the return value. If the processing is correctly completed, the value indicating that the processing has been correctly completed is returned as the return value.
  • the aforementioned operating system uses the data area "RBox” as a future, and also uses the data area "DeliveryBoxA" for delivering information from the client object to the server object.
  • the aforementioned operating system uses the data area "Continuation” as a future, and also uses the data area "DeliveryBoxB" for delivering information from the client object to the server object.
  • the above-described operating system reserves the data area "Thread” for each object in order to store the information used for managing the execution state of the object.
  • the operating system also stores the information concerning the future in the data area "Thread”.
  • the object is operating as a single thread in the mCOOP metaSpace and in the mDrive metaSpace, one thread corresponding to one object.
  • the information concerning the thread is stored in the data area "Thread" as the information for managing the execution state of the object.
  • the data areas "RBox”, “DeliveryBoxA”, “Continuation”, “DeliveryBoxB”, and “Thread” are data areas used by the operating system for providing the function of the message passing or for managing the object. These data areas are managed by the operating system so that they cannot be directly accessed by the application programs or the device drivers. The above-described data areas are discussed in detail below.
  • the data area "RBox” is reserved by the object “mCOOPMailer” upon issuing the method "SendWithRBox". More specifically, the reservation of the data area "RBox” by the object “mCOOPMailer” is performed by creating the instances of a class (hereinafter referred to as the "class 'RBox'") having attributes shown in Table 1. In Table 1, among the attributes of the class "RBox", only a minimal number of attributes required for implementing the basic form of message passing in the mCOOP metaSpace are shown. Attributes other than the attributes shown in Table 1 may be included. Table 1 RBox ThreadID creator bool ready void* resultMsg t_size sizeOfResultMsg sError status
  • Table 1 shows that the class "RBox” has an attribute "creator” of the "ThreadID” type, which is a data type for specifying the data area "Thread” to be set for each object.
  • the class "RBox” also has an attribute “ready” of the "bool” type, which is a data type for logical values, an attribute “resultMsg” of the "void*” type, which is a data type representing the pointer, and an attribute “sizeOfResultMsg” of the "size_t” type, which is a data size for specifying the size of the data.
  • attributes are used as the area for storing the result data of the processing executed by the server object.
  • the class "RBox” further has an attribute "status" of the "sError” type, which is a data type indicating the error code, as the area for storing the data representing the status of the server object.
  • the identifier for specifying the data area "Thread” corresponding to the object that has created the data area "RBox" is set in the attribute "creator".
  • the object is operating as a single thread, as discussed above, and one data area "Thread” is assigned to one object. Accordingly, if the data area "Thread” is specified by the attribute "creator", the corresponding client object is determined.
  • the value indicating whether the processing result of the server object has been returned is set in the attribute "ready".
  • the attribute "ready" is a flag indicating whether the result message to be returned from the server object to the client object is ready.
  • the pointer to the area for storing the message to be delivered to the client object as the processing result of the server object is set in the attribute "resultMsg".
  • the value representing the size of the message to be delivered to the client object as the processing result of the server object is set in the attribute "sizeOfResultMsg".
  • the code indicating the status of the server object as the information to be reported to the client object is set in the attribute "status". More specifically, if the processing of the server object is not correctly completed due to the occurrence of an exception interrupting the normal execution of the server object, the message indicating a failure in performing normal processing is reported to the object "mCOOPMailer" from the object "mCOOPFaultHandler", which will be discussed later. Thus, the error code indicating the status of the server object is set in the attribute "status" by the object "mCOOPMailer". If the processing is correctly executed by the server object, the value indicating that the server object is in a normal status is set in the attribute "status".
  • the client object refers to the attribute "ready” so as to determine whether the result of the processing executed by the server object has been returned. If the processing result of the server object has been returned, the client object refers to the attribute "resultMsg" so as to specify the area for storing the message to be delivered to the client object as the processing result of the server object, thereby reading the data having the size indicated by the attribute "sizeOfResultMsg" from the above-mentioned area. As a result, the message to be delivered to the client object is read and delivered to the client object.
  • the data area "DeliveryBoxA” is reserved by the object “mCOOPMailer” to deliver information from the client object to the server object. More specifically, the reservation of the data area "DeliveryBoxA" by the object “mCOOPMailer” is performed by creating the instances of a class (hereinafter referred to as the "class 'DeliveryBoxA'" having attributes shown in Table 2. In Table 2, among the attributes of the class "DeliveryBoxA", only a minimal number of attributes required for implementing the basic form of message passing in the mCOOP metaSpace are shown. Attributes other than the attributes shown in Table 2 may be included. Table 2 DeliveryBoxA RID rBoxID void* msg t_size sizeOfMsg
  • Table 2 shows that the class "DeliveryBoxA” has an attribute "rBoxID” of the "RID” type, which is a data type for specifying the data area "RBox", an attribute “msg” of the "void*” type, which is a data type indicating the pointer, and an attribute "sizeOfMsg” of the "size_t” type, which is a data size for designating the size of the data.
  • the identifier for specifying the data area "RBox” used for performing message passing using the data area "DeliveryBoxA” is set in the attribute "rBoxID”.
  • the pointer to the area for storing the message to be delivered from the client object to the server object is set in the attribute "msg".
  • the value representing the size of the message to be delivered from the client object to the server object is set in the attribute "sizeOfMsg".
  • the operating system is able to send the information concerning the data area "RBox” together with the message that is sent from the client object to the server object.
  • the operating system is able to simultaneously handle the message and the future in the mCOOP metaSpace.
  • the data area "Continuation” is reserved by the object "mDriveMailer” in order to store the information concerning the continuation method therein. More specifically, the reservation of the data area "Continuation" by the object "mDriveMailer” is performed by creating the instances of a class (hereinafter referred to as the "class 'Continuation”') having attributes indicated in Table 3. In Table 3, among the attributes of the class "Continuation”, only a minimal number of attributes required for implementing the basic form of message passing in the mDrive metaSpace are shown. Attributes other than the attributes shown in Table 3 may be included. Table 3 Continuation ThreadID creator Selector meth
  • Table 3 indicates that the class "Continuation” has an attribute “creator” of the "ThreadID” type, which is a data type for specifying the data area "Thread” set for each object, and an attribute “meth” of the "Selector” type, which is a data type for designating the method.
  • the identifier for specifying the data area "Thread” corresponding to the object that has created the data area "Continuation" is set in the attribute "creator".
  • the object is operating as a single thread, as discussed above, and one data area "Thread” corresponds to one object. Accordingly, when the data area "Thread” is specified by the attribute "creator", the corresponding client object is determined.
  • the value representing the continuation method of the client object is set in the attribute "meth".
  • the client object refers to the attribute "meth" so as to specify the continuation method of the client object, thereby starting the specified continuation method.
  • the identifier for specifying the data area "Continuation" used for message passing employing the data area "DeliveryBoxB" is set in the attribute "contID”.
  • the pointer to the area for storing the message to be delivered from the client object to the server object is set in the attribute "msg".
  • the object is operating as a single thread, and one thread is assigned to one object.
  • the information concerning each thread is stored in the data area "Thread" as the information for managing the execution state of the object. That is, the operating system reserves the data area "Thread” for each object in order to store the information for managing the execution state of the object therein.
  • the object is operating in the mCOOP metaSpace.
  • the identifier "rBoxID" for specifying the data area "RBox” used for message passing is stored by the object "mCOOPMailer", as the information concerning the future, in the data area "Thread” corresponding to the object.
  • the object B In starting the method of the object B by delivering the data stored in the data area "DeliveryBoxA" from the object "mCOOPMailer” to the object B, the object B is specified by the argument “destObjID” of the method “SendWithRBox”, and the method of the object B is designated by the argument "meth" of the method "SendWithRBox".
  • the result of the processing executed by the object C is delivered to the object A, and it is as if the object A and the object C were concurrently operating.
  • the data area "RBox” and the identifier "rBoxID” for specifying the data area "RBox” are transparent to the application programs. This enhances the simplicity of the development of application programs.
  • the object A can resume the execution state from the waiting state, which would otherwise cause the object A to enter the waiting state and would stop the system.
  • the object "mDriveMailer” first reserves the data area "Continuation”, and stores the information concerning the continuation method therein. More specifically, the value of the identifier for specifying the data area "Thread” corresponding to the object A is set in the attribute "creator” of the data area "Continuation”, and also, the value of the argument “contMeth” of the method "SendWithContinuation” is set in the attribute "meth" of the data area "Continuation”.
  • the object "mDriveMailer” also reserves the data area "DeliveryBoxB", and stores the identifier "contID” for designating the data area "Continuation”, and the message sent by the method "SendWithContinuation” therein.
  • the identifier "contID” for specifying the data area "Continuation” is stored in the data area "DeliveryBoxB", and more specifically, the value of the identifier "contID” for specifying the data area "Continuation” is set in the attribute "contID" of the data area "DeliveryBoxB".
  • the message sent by the method "SendWithContinuation” is stored in the data area "DeliveryBoxB", and more specifically, the value of the argument “msg” of the method “SendWithContinuation” is stored in the attribute "msg" of the data area "DeliveryBoxB”, and also, the value of the argument "sizeOfMsg” of the method “SendWithContinuation” is set in the attribute "sizeOfMsg" of the data area "DeliveryBoxB".
  • the object "mDriveMailer” Upon completing the above-described processing, the object "mDriveMailer" returns to the object A, as indicated by the single-dot-chain arrow ST4-5, the value indicating that the processing has been correctly completed, as the return value to the method "SendWithContinuation", and then enables the object A to restart processing. Accordingly, the object A is ready to execute processing, and if there is any remaining processing, the object A restarts the processing.
  • the object B executes the method "B::B1", and upon completing the processing requested by the object A, the object B issues the method "Kick", as indicated by ST4-7.
  • the processing is shifted to the object "mDriveMailer", as represented by the single-dot-chain arrow ST4-8, and the processing in response to the method "Kick” is performed by the object "mDriveMailer", as indicated by ST4-9.
  • the object "mDriveMailer” first specifies the data area "Continuation” based on the argument “contID” of the method "Kick”, and then reads the information stored in the data area "Continuation".
  • the object “mDriveMailer” Upon correctly completing the start of the continuation method "A::A2" of the object A, the object “mDriveMailer” returns to the object B, as indicated by the single-dot-chain arrow ST4-11, the value indicating that the processing of the method "Kick” has been correctly completed, as the return value to the method "Kick".
  • the object "mDriveMailer” then enables the object B to restart processing. Accordingly, the object B is ready to execute processing, and if there is any remaining processing, the object B restarts the processing.
  • the continuation method "A::A2" of the object A is started by the object B, as designated by the solid arrow ST4-12, and it is as if the object A and the object B were concurrently operating, from the point of view of the device drivers.
  • FIG. 8 illustrates message passing among an object A operating as an application program in the mCOOP metaSpace, an object B operating as an application program in the mCOOP metaSpace, and an object C operating as a device driver in the mDrive metaSpace.
  • the object B delegates the reply authorization to the object C.
  • the object A is a client object
  • the object B and the object C are server objects.
  • the object B delegates the object C to return the processing result to the object A. That is, the object B serves as a server object and also as an authorization-delegating object.
  • the object C serves as a server object and also as an authorization-delegated object.
  • steps ST5-1, ST5-2, ST5-3, ST5-4, ST5-5, ST5-6, ST5-7, ST5-8, ST5-9, and ST5-10 shown in Fig. 8 are respectively similar to ST3-1, ST3-2, ST3-3, ST3-4, ST3-5, ST3-6, ST3-7, ST3-8, ST3-9, and ST3-10 shown in Fig. 2, and an explanation thereof will thus be omitted.
  • step ST5-10 when the object A is in the waiting state, and when the object B is executing processing, the object B issues the method "Delegate" for delegating the reply authorization.
  • the object "mCOOPMailer” determines whether the authorization-delegated object is an object operating in the mCOOP metaSpace. If it is found that the authorization-delegated object is an object operating in the mCOOP metaSpace, the processing proceeds in accordance with the scenario shown in Fig. 6. In this example, however, the authorization-delegated object is not an object operating in the mCOOP metaSpace, but is the object C operating in the mDrive metaSpace. Accordingly, the processing is shifted from the object "mCOOPMailer" to the object "mDriveMailer", as represented by the single-dot-chain arrow ST5-14.
  • the identifier "rBoxID” stored in the data area "Thread" corresponding to the object B is erased, thereby depriving the object B of the reply authorization. That is, the object B loses the reply authorization by issuing the method "Delegate”, and delegates the reply authorization to the object C. Since the object B has lost the reply authorization, it is unable to issue the method "Reply”. In other words, the object B has issued the method "Delegate” instead of the method "Reply".
  • the object "mDriveMailer” also stores the message sent by the method "Delegate” in the data area "DeliveryBoxB". More specifically, the value of the argument "msg" of the method “Delegate” is set in the attribute "msg" of the data area "DeliveryBoxB", and also, the value of the argument "sizeOfMsg” of the method "Delegate” is set in the attribute "sizeOfMsg" of the data area "DeliveryBoxB".
  • the identifier "rBoxID” is stored in the data area "Thread” corresponding to the object C.
  • the identifier "rBoxID” to be delivered to the object C is under the management of the operating system, and it is only the message that has been sent to the object C, from the point of view of the application program.
  • the object C is specified by the argument “destObjID” of the method "Delegate”, and the method of the object C is designated by the argument “meth” of the method "Delegate”.
  • the object "mDriveMailer” Upon completing the aforementioned processing, the object "mDriveMailer” returns to the object B via the object “mCOOPMailer", as indicated by the single-dot-chain arrows ST5-17 and ST5-18, the value indicating that the processing has been correctly completed, as the return value to the method "Delegate”, and then enables the object B to restart processing.
  • the object B is now ready to execute processing, and if there is any remaining processing, the object B restarts the processing.
  • the reply authorization has been delegated form the object B to the object C, as indicated by the solid arrow ST5-19, and it is as if the object B and the object C were concurrently operating, from the point of view of the application programs.
  • the object C issues the method "Kick", as designated by ST5-20.
  • the processing is shifted to the object "mDriveMailer", as represented by the single-dot-chain arrow ST5-21, and the processing in response to the method "Kick” is executed by the object "mDriveMailer", as indicated by ST5-22.
  • the object "mDriveMailer” reads the information stored in the data area "Thread” corresponding to the object C. If the identifier "contID” specifying the data area “Continuation” is stored in the data area "Thread", the processing for starting the continuation method proceeds in accordance with the scenario shown in Fig. 7. In this ' example, however, not the identifier "contID” designating the data area "Continuation”, but the identifier "rBoxID” specifying the data area "RBox” is stored in the data area "Thread".
  • a shift of the processing from the object "mDriveMailer” to the object “mCOOPMailer” is performed via the micro-kernel. More specifically, the object “mDriveMailer” first checks whether the identifier stored in the data area "Thread” corresponding to the object C is the identifier "contID” for specifying the data area "Continuation” used in the mDrive metaSpace. In this example, it is determined that the identifier stored in the data area "Thread” corresponding to the object C is not the identifier "contID” designating the data area "Continuation”.
  • the information for determining the metaSpace in which the object to be communicated by message passing is operating is also stored in the data area "Thread" corresponding to each object.
  • the identifier stored in the data area "Thread” corresponding to the object C is not the identifier "contID" for specifying the data area "Continuation”.
  • the data area "Thread” corresponding to the object C is further examined to determine the metaSpace in which the object to be communicated by message passing is operating.
  • the metaSpace in which the object to be communicated by message passing is operating is a mCOOP metaSpace.
  • the object "mDriveMailer” requests the object "mCOOPMailer", which is a metaObject for performing message passing between the objects operating in the mCOOP metaSpace, to execute the required processing.
  • the processing is shifted from the object "mDriveMailer” to the object "mCOOPMailer".
  • the object "mCOOPMailer” delivers the result of the processing executed by the object C to the object A. If the object A has not yet issued the method "Receive”, the object “mCOOPMailer” stores the processing result of the object C in the data area "RBox".
  • the object “mCOOPMailer” immediately delivers to the object A, as designated by the single-dot-chain arrow ST5-25, the processing result of the object C without storing it in the data area "RBox".
  • the object "mCOOPMailer” Upon correctly completing the processing for the delivery of the processing result of the object C to the object A, the object “mCOOPMailer” returns to the object C via the object "mDriveMailer", as represented by the single-dot-chain arrows ST5-26 and ST5-27, the value indicating that the processing has been correctly completed, as the return value to the method "Kick".
  • the "mCOOPMailer” then enables the object C to restart processing.
  • the object C is now ready to execute processing, and if there is any remaining processing, the object C restarts the processing.
  • the result of the processing executed by the object C has been sent to the object A, as indicated by the solid arrow ST5-28, and it is as if the object A and the object C were concurrently operating, from the point of view of the application programs.
  • the method “Receive” has been issued before the method “Kick” is issued.
  • the method “Receive” may be issued after the method “Kick” has been issued.
  • the object A is able to immediately receive the result of the processing executed by the object C without entering the waiting state.
  • the object "mCOOPMailer” executes the following processing.
  • the object “mCOOPMailer” stores the processing result of the object C in the data area "RBox" when the method "Kick” is issued by the object C. Then, when the object A issues the method "Receive", the "mCOOPMailer" immediately reads the processing result of the object C from the data area "RBox" and delivers it to the object A.
  • the result of the processing executed by the object C is stored in the data area "RBox". More specifically, the value indicating that the processing result of the object C has been returned is set in the attribute "ready" of the data area "RBox", and the pointer to the area for storing the message to be delivered to the object A as the processing result of the object C, i.e., the pointer represented by the argument "msg" of the method "Kick", is set in the attribute "resultMsg" of the data area "RBox".
  • the value indicating the size of the message to be delivered to the object A as the processing result of the object C i.e., the value represented by the argument "sizeOfMsg" of the method "Kick" is set in the attribute "sizeOfResultMsg" of the data area "RBox".
  • the object “mCOOPMailer” In reading the processing result of the object C from the data area "RBox” and delivering it to the object A, the object “mCOOPMailer” first reads the attribute "resultMsg" and the attribute "sizeOfResultMsg” of the data area "RBox” from the data area "RBox” which is specified by the argument "rBoxID” of the method “Receive”, and then reads the data having the size indicated by the attribute "sizeOfResultMsg" from the area represented by the attribute "resultMsg". The read data serves as a message to be delivered from the object C to the object A. The object “mCOOPMailer” then stores the read data in the area indicated by the argument "msg" of the method “Receive". The size of the area designated by the argument “msg” of the method “Receive” has been set by the argument "sizeOfMsg" of the method "Receive".
  • the result of the processing executed by the object C is delivered to the object A, and it is as if the object A and the object C were concurrently operating.
  • the object "mCOOPMailer” sets in the attribute "status” of the data area "RBox” the error code indicating that the object C has become inoperable due to the occurrence of an error. Then, when the object A issues the method "Receive”, the object “mCOOPMailer” reads the error code set in the attribute "status” of the data area "RBox", and returns the error code to the object A as the return value to the method "Receive”. The object "mCOOPMailer” then enables the object A to restart processing. Accordingly, the object A is ready to execute processing, and if there is any remaining processing, the object A restarts the processing.
  • the object A can be resumed to the execution state from the waiting state, which would otherwise cause the object A to enter the waiting state and would stop the system.
  • the present invention offers the following advantages.
  • the status of the server object can be informed to the client object without needing to execute time-out processing, thereby enabling the client object to exit from the waiting state.
  • the data indicating the status of the server object is delivered to the client object via the above-described data area, which would otherwise waste time, as in the case in which time-out processing is executed.
  • the client object can speedily exit from the waiting state.
  • the data indicating the status of the server object is delivered to the client object when the processing executed by the server object is not correctly completed, thereby making it possible to specify the cause for the occurrence of a waiting state. Accordingly, the processing can be performed to suitably overcome the cause, thereby preventing the occurrence of another waiting state for the same reason.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Claims (7)

  1. Datenverarbeitungsverfahren, bei dem eine Meldung von einem Clientenobjekt (20) zu einem ersten Serverobjekt (30) gesendet wird (ST3-6), wobei das erste Serverobjekt (30) eine Verarbeitung als Antwort auf eine Anforderung (ST3-1) in der Meldung ausführt und ein Ergebnis der Verarbeitung an das Clientenobjekt (20) zurückbringt, wobei das Verfahren folgende Schritte aufweist:
    Reservieren (ST2-3) eines Ergebnisdatenbereichs zum Speichern von Ergebnisdaten, welche das Ergebnis der Verarbeitung zeigen, welche durch zumindest das erste Serverobjekt (30) auszuführen ist, und eines Statusdatenbereichs zum Speichern von Statusdaten, welche einen Status des ersten Serverobjekts (30) zeigen, beim Senden der Meldung vom Clientenobjekt (20) zum Serverobjekt (30);
    wobei das Serverobjekt (30), welches die Meldung vom Clientenobjekt (20) empfing, zu einem anderen Serverobjekt (40) die Bevollmächtigung delegiert, um eine Antwort an das Clientenobjekt (20) zurückzubringen;
    Speichern (ST3-17) der Ergebnisdaten im Ergebnisdatenbereich, wenn die Verarbeitung, welche durch zumindest das delegierte Serverobjekt (40) ausgeführt wird, korrekt beendet wurde, oder Speichern der Statusdaten im Statusdatenbereich, wenn die Verarbeitung, welche durch zumindest das delegierte Serverobjekt (20) ausgeführt wurde, nicht korrekt beendet wurde;
    wobei das Clientenobjekt (20) sowohl die Ergebnisdaten als auch die Statusdaten anfordert und das Clientenobjekt (20) in einen Wartezustand eintritt;
    wobei das Clientenobjekt (20) die Ergebnisdaten durch Lesen der Daten empfangt (ST3-22), welche im Ergebnisdatenbereich gespeichert sind, wenn die Verarbeitung, welche durch das zumindest delegierte Serverobjekt (40) ausgeführt wird, korrekt beendet wurde, oder wobei das Clientenobjekt (20) die Statusdaten durch Lesen der Daten im Statusdatenbereich empfängt, wenn die Verarbeitung, welche durch zumindest das delegierte Serverobjekt (40) ausgeführt wird, nicht korrekt beendet wurde; und
    wobei das Clientenobjekt einen Betriebszustand beim Empfangen eines von Ergebnisdaten und Statusdaten wieder aufnimmt, wobei
    das Verfahren weiter die Verwendung eines Metaobjekts (70) aufweist, um eine Meldungsweitergabe zwischen dem Clientenobjekt (20) und den Serverobjekten (30. 40) durchzuführen, wobei
    das Senden der Meldung (ST3-6) darin besteht,
    dass das Clientenobjekt (20) eine Anforderung zur Verarbeitung zum Metaobjekt (70) sendet (ST3-2) und das Metaobjekt (70) die Meldung vom Clientenobjekt (20) zu dem ersten Serverobjekt (30) liefert;
    das Metaobjekt (70) den Reservierungsschritt durchführt (ST3-3);
    das erste Serverobjekt (30) die Verarbeitung als Antwort auf die Meldung beginnt;
    der Delegierungsschritt (ST3-16) darin besteht,
    dass das erste Serverobjekt (30) eine Berechtigung sendet (ST3-12), um das Verarbeitungsergebnis zum Metaobjekt (70) zurückzubringen, und
    das Metaobjekt (70) die Meldung zum zweiten Serverobjekt (40) liefert, welche vom ersten Serverobjekt (30) gesendet wurde;
    der Speicherschritt (ST3-17) darin besteht,
    dass das zweite Serverobjekt (40) das Verarbeitungsergebnis zum Metaobjekt (70) sendet und dem Metaobjekt (70) das Verarbeitungsergebnis im Ergebnisdatenbereich speichert (ST3-19), oder
    dass in dem Fall, wo die Verarbeitung des zweiten Serverobjekts (40) Unterbrochen (ST2-11) wird, eine Ausnahmeinformation zum Metaobjekt (70) gesendet wird (ST2-12, ST2-14) und das Metaobjekt (70) einen Fehlercode im Statusdatenbereich speichert, und
    der Empfangsschritt (ST3-22) darin besteht,
    dass das Metaobjekt (70) nach Anforderung (ST3-8) durch das Clientenobjekt (20) das Verarbeitungsergebnis oder den Fehlercode (ST2-15) zum Clientenobjekt (20) liefert (ST3-20).
  2. Datenverarbeitungsverfahren nach Anspruch 1, welches außerdem den Schritt aufweist:
    Steuern des Clientenobjekts, um im Wartezustand zu bleiben, bis die Ergebnisdaten oder die Statusdaten im Ergebnisdatenbereich bzw. im Statusdatenbereich gespeichert sind.
  3. Datenverarbeitungsverfahren nach den Ansprüchen 1 oder 2, wobei das Metaobjekt (70) ein Mailer-Objekt (50) und ein Fehlerbehandlungsobjekt (60) aufweist, wobei:
    in dem Fall, wo die Verarbeitung des zweiten Serverobjekts (40) unterbrochen ist (ST2-11), Ausnahmeinformation zum Fehlerbehandlungsobjekt (40) gesendet wird (ST2-12) wird, das Fehlerbehandlungsobjekt (60) die Ausnahme handhabt (ST2-13) und einen Fehlercode zum Mailer-Objekt (50) zur Speicherung im Statusdatenbereich zurückbringt (ST2-14).
  4. Aufzeichnungsmedium (6), auf welchem ein Betriebssystem aufgezeichnet ist, welches in Verwendung die Schritte gemäß dem Verfahren nach einem der Ansprüche 1 bis 3 durchführt.
  5. Aufzeichnungsmedium (6) nach Anspruch 4, wobei das Betriebssystem eine Datenleseeinrichtung aufweist, um die Ergebnisdaten und die Statusdaten, die Daten, welche im Ergebnisdatenbereich bzw. im Statusdatenbereich gespeichert sind, zu lesen.
  6. Aufzeichnungsmedium (6) nach Anspruch 5, wobei das Betriebssystem eine Steuereinrichtung (5) aufweist, um das Clientenobjekt zu steuern, um im Wartezustand zu bleiben, bis die Ergebnisdaten oder die Statusdaten im Ergebnisdatenbereich bzw. im Statusdatenbereich gespeichert sind.
  7. Datenverarbeitungsvorrichtung, welches ein Aufzeichnungsmedium (6) nach einem der Ansprüche 4 bis 6 aufweist.
EP99301646A 1998-03-04 1999-03-04 Datenverarbeitungsverfahren Expired - Lifetime EP0940750B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP10052494A JPH11249918A (ja) 1998-03-04 1998-03-04 データ処理方法、記録媒体及びデータ処理装置
JP5249498 1998-03-04

Publications (3)

Publication Number Publication Date
EP0940750A2 EP0940750A2 (de) 1999-09-08
EP0940750A3 EP0940750A3 (de) 2003-11-26
EP0940750B1 true EP0940750B1 (de) 2007-08-08

Family

ID=12916279

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99301646A Expired - Lifetime EP0940750B1 (de) 1998-03-04 1999-03-04 Datenverarbeitungsverfahren

Country Status (9)

Country Link
US (1) US6356904B1 (de)
EP (1) EP0940750B1 (de)
JP (1) JPH11249918A (de)
KR (1) KR19990077559A (de)
CN (1) CN1231440A (de)
AU (1) AU757763B2 (de)
ID (1) ID22790A (de)
SG (1) SG97782A1 (de)
TW (1) TW424194B (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003150424A (ja) * 2001-11-16 2003-05-23 Fujitsu Ltd ファイルシステム、制御方法及びプログラム
US7676791B2 (en) * 2004-07-09 2010-03-09 Microsoft Corporation Implementation of concurrent programs in object-oriented languages
US7970740B1 (en) * 2004-09-23 2011-06-28 Oracle America, Inc. Automated service configuration snapshots and fallback
US7549151B2 (en) * 2005-02-14 2009-06-16 Qnx Software Systems Fast and memory protected asynchronous message scheme in a multi-process and multi-thread environment
US7840682B2 (en) 2005-06-03 2010-11-23 QNX Software Systems, GmbH & Co. KG Distributed kernel operating system
US8667184B2 (en) * 2005-06-03 2014-03-04 Qnx Software Systems Limited Distributed kernel operating system
US7680096B2 (en) * 2005-10-28 2010-03-16 Qnx Software Systems Gmbh & Co. Kg System for configuring switches in a network
JP6136980B2 (ja) * 2014-02-27 2017-05-31 富士ゼロックス株式会社 情報処理システム及びプログラム
JP6288467B2 (ja) * 2015-04-17 2018-03-07 京セラドキュメントソリューションズ株式会社 電子機器

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU599856B2 (en) * 1988-09-08 1990-07-26 Digital Equipment Corporation Local area system transport
GB9314460D0 (en) * 1993-07-13 1993-08-25 Int Computers Ltd Computer systems integration
US6253252B1 (en) * 1996-07-11 2001-06-26 Andrew Schofield Method and apparatus for asynchronously calling and implementing objects
US6003136A (en) * 1997-06-27 1999-12-14 Unisys Corporation Message control system for managing message response in a kerberos environment
US6009175A (en) * 1997-06-27 1999-12-28 Unisys Corporation Asynchronous message system for menu-assisted resource control program
US6175920B1 (en) * 1998-02-20 2001-01-16 Unisys Corporation Expedited message control for synchronous response in a Kerberos domain
US6092178A (en) * 1998-09-03 2000-07-18 Sun Microsystems, Inc. System for responding to a resource request

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
ID22790A (id) 1999-12-09
JPH11249918A (ja) 1999-09-17
AU757763B2 (en) 2003-03-06
EP0940750A2 (de) 1999-09-08
KR19990077559A (ko) 1999-10-25
US6356904B1 (en) 2002-03-12
AU1845299A (en) 1999-09-16
EP0940750A3 (de) 2003-11-26
TW424194B (en) 2001-03-01
SG97782A1 (en) 2003-08-20
CN1231440A (zh) 1999-10-13

Similar Documents

Publication Publication Date Title
US7233972B2 (en) Method and apparatus for coordination of client/server processes
US7058950B2 (en) Callback event listener mechanism for resource adapter work executions performed by an application server thread
US6615303B1 (en) Computer system with multiple operating system operation
US6961926B2 (en) System and method for distributed debugging and recording medium on which control programs are recorded
US5748959A (en) Method of conducting asynchronous distributed collective operations
EP0924607A2 (de) Verfahren und Geraet fuer schnelle lokale CORBA Objektverweisungen
JPH08339305A (ja) サーバの非活動化と遮断を管理する方法および装置
US6754736B1 (en) Information processing apparatus, data inputting/outputting method, and program storage medium therefor
US20070124365A1 (en) Method, apparatus and program storage device that provides a user mode device interface
KR20040086214A (ko) 인핸스드 런타임 호스팅
US7962926B2 (en) Method, system, and program storage device for generating a retry message when a thread in a real-time application is unavailable to process a request to utilize the real-time application
EP0940750B1 (de) Datenverarbeitungsverfahren
EP0940749B1 (de) Datenverarbeitungsverfahren
US6598049B1 (en) Data structure identifying method and recording medium
CN113342554B (zh) Io多路复用方法、介质、设备和操作系统
EP1249764A2 (de) Prozessorsystem
CN114462388A (zh) 句柄管理或通信方法、电子设备、存储介质及程序产品
JP3823468B2 (ja) データ処理方法、記録媒体及びデータ処理装置
CN118012839B (zh) 文件服务系统在用户态传递文件布局的方法、装置及系统
EP4250109A1 (de) Aufrufverfahren für grafikverarbeitungseinheit, zentrale verarbeitungseinheit und vorrichtung
JPH11184712A (ja) 情報処理装置
CN115756849A (zh) 微内核操作系统中内存分配方法、装置、设备及介质
JP2003177929A (ja) マスタマシン、スレーブマシン、およびそれらを有するクラスタリングシステム
JPH1040119A (ja) 仮想計算機のコンソール制御システム

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17P Request for examination filed

Effective date: 20040428

AKX Designation fees paid

Designated state(s): GB IT NL

REG Reference to a national code

Ref country code: DE

Ref legal event code: 8566

17Q First examination report despatched

Effective date: 20041004

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): GB IT NL

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20080509

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20080304

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081001

NLV4 Nl: lapsed or anulled due to non-payment of the annual fee

Effective date: 20081001

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20080304

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20080304