According to the OMG CORBA C++ Mapping version 1.1, all constructors, copy constructors and assignment operators should be moved to "protected" section in class declarations. Since the current MS Visual C++ 6.0 compiler will cause some problems to TAO's exception mechanism, we defer doing this until we drop support for MSVC++ 6.
Narrowing a LocalObject to a CORBA::Object is broken right now. The solution seems to be making CORBA::Object an abstract base class and create a CORBA::RemoteObject for regular object. Or, even easier, add a is_local member into CORBA::Object. I'll take the easier route for now.
I'm almost sure this class will require a callback interface for AMIs sent with SYNC_NONE policy. Those guys need to hear when the connection timeouts or closes, but cannot block waiting for the message to be delivered.
This lock should be strategized so that we dont lock in single threaded configurations. It is not possible to do this now as most of the information is available in the ORB_Core which is not available here.
Implementing the Leader/Followers loop in this class, as well as the callbacks to communicate that an event has completed leads to excessive coupling. A better design would use a separate class to signal the events, that would allow us to remove the Leader/Followers logic from the ORB. However, that requires other major changes and it somewhat complicates the design.
In the future this hook should change, instead of hardcoding the object we should add a "Resolver" to the ORB, so the "POACurrent" object returns a per-ORB object.
Change the ORB to allocate oneway and AMI buffer from global memory, to avoid the data copy in this path. What happens if the there is no queueing? Can we check that before allocating the memory?
We should implement this as a base template, something like: template<class T> Intrusive_Node { public: void next (T *); T* next () const; private: T* next_; }; and use it as follows: class TAO_Queued_Message : public Intrusive_Node<TAO_Queued_Message> { };
Why do we need both a reference to the ORB_Core and its ORB? It think the memory management rules for the ORB_Core changed, in the good old days it was the CORBA::ORB class who owned the ORB_Core, now it is the other way around....
The class name (Sync_Strategy) is inherited from the policies (SyncScopePolicy), but Queueing_Strategy probably captures its intent better. It should be changed in a future revision of the ORB.
Member TAO_Thread_Per_Connection_Handler::activate (long flags=THR_NEW_LWP, int n_threads=1, int force_active=0, long priority=ACE_DEFAULT_THREAD_PRIORITY, int grp_id=-1, ACE_Task_Base *task=0, ACE_hthread_t thread_handles[]=0, void *stack[]=0, size_t stack_size[]=0, ACE_thread_t thread_names[]=0)
Since we only use a limited functionality of ACE_Svc_Handler we could probably implement a generic adapter class (TAO_Transport_Event_Handler or something), this will reduce footprint and simplify the process of implementing a pluggable protocol.
I think this method is pretty much useless, the connections are *always* registered with the Reactor, except in thread-per-connection mode. In that case putting the connection in the Reactor would produce unpredictable results anyway.
Look into adding a template parameter to each of the templates in question that would be a trait containing the means for releasing references managed by the templates. Doing so should work around the non-dependent name issues in g++ 3.4, thus easing the requirement that this header be parsed last.
