The CORBA/IIOP 2.4.2 spec (formal/01-02-033) contains a small typo in
page 24-21, section 24.13 "Real-Time Current", second paragraph after the
code segment. It reads "PrioirtyMapping::to_native" (note the reversed 'ir'
in PriorityMapping).

Fig. 5.5, Although it is repeated and emphasized under Error Handling subtitle (on page 15), I propose that the following words "reset_component" be added on the return path from Error[1], Error[2], and Error[3] to Inactive[1], Inactive[2] and Inactive[n] respectively. There is no harm in repeating the same as long as it makes the specification clear to understand.

General Comment: I propose the inclusion of a chapter on "Definitions" of some terms that may not seem obvious to some developers/users. May be it is not a requirement by OMG, but it is the International Practice to define some terms in such a specification.

The RT-CORBA specification, even after the FTF modifications
(pt/00-09-02) reads:

-----------------------------
4.12.2 Binding of Priority Banded Connection

[6th paragraph]
.... Having done this the ORB shall send a "SUCCESS" Reply message. If
the.....

-----------------------------

No definition for what form this SUCCESS reply should take. One should
assume that it is a regular GIOP Reply message, with the reply_status set to
NO_EXCEPTION. The spec is at least misleading, should the string "SUCCESS"
be returned? Or should a boolean value of "SUCCESS" be returned? Or just
returning an empty reply is enough?

Suggested fixes:

1) Define the _bind_priority_band() [pseudo?-]operation using IDL, that
would at least clarify the contents of all messages, something like the
following:

module CORBA {
// PIDL
interface Object

;

2) Change the paragraph to read:

When a Real-Time-ORB receives a _bind_priority_band Request it should
allocate

resources to the connection and configure those resources appropriately to
the priority

band indicated in the ServiceContext. Having done this the ORB shall send a
GIOP Reply

message with the reply_status field set to NO_EXCEPTION.

Remove "RTObject owner;" from the ExecutionContextProfile struct.

The heading "Ownership and Participation" should be changed to "Participation" to reflect the new relationship between LightweightRTObjects and ExecutionContexts.

Section 5.2.2.2.8 should be removed to reflect the get_owned_contexts() method being removed.

Remove the get_owned_contexts() method from the LightweightRTObject interface.

The ExecutionContext will not be owned by a LightweightRTObject, so the "owner" field should be removed from the ExecutionContextProfile structure.

In Figure 5.3, ExecutionContext may be a composite member of a LightweightRTC. This relationship will be removed. RTCs will not own ECs, they will only participate in them.

The first paragraph under "Ownership and Participation" should be removed, as LightweightRTObjects will not own ExecutionContexts if other changes are approved.

The get_owned_contexts() method shall be removed. RTCs will no longer be able to own ECs, they will only participate in them.

Change "An autonomous RTC" to "An RTC" under "Ownership and Participation".

Proposal to extend the TCPProtocolProperties to the definition below. Add debug/host/port. debug to control SO_DEBUG. host/port to limit a POA to a certain host/port number local interface TCPProtocolProperties : ProtocolProperties

;

In this section, which describes the RTCORBA Current, the attribute thereon that holds the thread's priority is said to be called: 'base_priority'. In the consolidated IDL and separate IDL download no such attribute exists. Current has instead an attribute 'the_priority'. Seems an obvious error - just need to call for one or the other.

Dynamic threads in RTCORBA Threadpools. With RTCorba it is possible to create thread pools with dynamic threads. These threads may be additionally created by the ORB when needed. But the spec says about the destruction that it is an implementation issue, but it is really the application programmer that can make a decission about this instead of just the ORB. The only real possible option an ORB builder has is to keep the thread alive or destroy it after each invocation. We propose to extend the RTCORBA interface with an interface that is called back by the ORB so that it is to the application programmer to decide what should be done with the thread. Below is a possible proposal: This is the current implementation and the CORBA spec says it is up to the implementor, but it is now up to the ORB builder, not to the application programmer who is the correct person to decide what the do with a dynamic thread. To be able to let the application programmer decide this we need a special callback interface. A proposal would be to add the following: module RTCORBA { local interface DynamicThreadManager

; local interface RTORB

; }; At the moment the ORB decided that a dynamic thread is not needed anymore, it will callback to the application programmer. It is now up to the application programmer what to do, when returning true it will keep the thread alive, if false, it will end the thread.

RTCurrent is defined as following: local interface Current : CORBA::Current

; But it should be: local interface Current : CORBA::Current

; This is ok in 2.16 but not ok in 2.6

The applications based on Real-Time CORBA need analyze request header in order to get the request priority embedded in request header. Before analyzing request header, server-side ORB can not know the priority of request. In multi-threaded ORB, there are many threads serving client’s requests concurrently. At the same time there is at least one thread which takes in charge receiving requests from network and identifying the priority of request ( below we refer to this thread as endpoint-thread, and refer to the thread serving request as request-thread ). It is very important that what priority we should set to the endpoint-thread. If endpoint-thread priority is too high, it will impact the execution of request-thread, that is to say, impact the process of received request. If endpoint-thread priority is too low, it cannot receive new request from clients, which may be urgent request, compared to current requests. So we suggest providing a priority policy, maybe it can be named EndpointThreadPriorityPolicy, which allowing user to set endpoint-thread priority according to his requirement. ORB should provide default priority value for EndpointThreadPriorityPolicy. Below is the possible idl interface: //idl module RTCORBA { //local interface EndpointThreadPriorityPolicy : CORBA::Policy

; }; Applications can use this policy at the time of creating POAMananger. For example:(in win32 REALTIME_PRIORITY_CLASS) //c++ CORBA::PolicyList pl; pl.length(1); pl[0] = rtORB >create_endpoint_thread_priority_policy(24); PortableServer::POAManager_var manager = poamanager_factory> create_POAManager("RootPOAManager",pl); through configuring endpoint_thread's priority, we can trade off the processing between rceived request and new arrival request .

The idl for RTCORBA::Current on this page is: module RTCORBA { local interface Current : CORBA::Current

; }; Whereas in the consolidated IDL the attribute name is actually 'the_priority' not 'base_priority'. All ORBs appear to have implemented using 'the_priority' IMHO this is a simple editorial fix.

At the end of 2.10 it says: The same threadpool may be associated with a number of different POAs, by using a ThreadpoolPolicy containing the same ThreadpoolId in each POA_create. POA_create should be create_POA

The RTCORBA::Priority type has the allowed values of 0-32767 but is defined as short, which is signed. Shouldn't we define it as unsigned short?