TAO_RTEvent  2.1.4
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Pages
Todo List
Member ACE_Scheduler_MAX_PRIORITIES
This should be defined in ACE (somehow) and only mapped here to some variables (and even that is doubtful).
File ECG_UDP_Receiver.h
The class makes an extra copy of the events, we need to investigate if closer collaboration with its collocated EC could be used to remove that copy.
File ECG_UDP_Sender.h
The class makes an extra copy of the events, we need to investigate if closer collaboration with its collocated EC could be used to remove that copy.
Class RtecEventChannelAdmin::Dependency
It has become painfully obvious that we don't need a complete RtecEventComm::Event to declare the dependency, simply the EventHeader would do.
Member RtecEventChannelAdmin::ProxyPushSupplier::connect_push_consumer (in RtecEventComm::PushConsumer push_consumer, in ConsumerQOS qos)
The TypeError exception is not used and should be removed.
Class RtecEventChannelAdmin::Publication
It has become painfully obvious that we don't need a complete RtecEventComm::Event to declare the publication, simply the EventHeader would do.
Member RtecEventComm::EventHeader::creation_time
Because the filtering language uses EventHeaders as filtering expressions (yeah, it sucks) we also use this field to pass timeout values into the EC filter.
Member TAO_EC_Filter::matches (const RtecEventComm::EventHeader &rhs, const RtecEventComm::EventHeader &lhs)
Should we strategize the algorithm used to match headers?
Class TAO_EC_Gateway_IIOP
: The class makes an extra copy of the events, we need to investigate if closer collaboration with its collocated EC could be used to remove that copy.
Member TAO_EC_Gateway_Sched::init (RtecEventChannelAdmin::EventChannel_ptr supplier_ec, RtecEventChannelAdmin::EventChannel_ptr consumer_ec, RtecScheduler::Scheduler_ptr supplier_sched, RtecScheduler::Scheduler_ptr consumer_sched, const char *consumer_name, const char *supplier_name)
part of the RT_Info is hardcoded, we need to make it parametric.
Class TAO_EC_ProxyPushSupplier
We don't need to provide a trivial filter, the object itself could short-circuit the filter() —> push() cycle when the EC is properly configured, we need to explore this...
Member TAO_EC_QUEUE_HWM
The high water mark and low water mark shouldn't be hardcoded, check http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=565
Class TAO_EC_SupplierControl_Adapter

Marina Spivak made the following observation: these classes and implementation seem nearly identical to those in EC_Reactive_ConsumerControl.* The only differences are using consumer_admin collection vs supplier_admin, and calling disconnect_push_consumer vs disconnect_push_supplier ... Seems like it may be a good idea to change some naming and templatize...

The same templates should be used for the Notification and COS Event services.

Class TAO_ECG_CDR_Message_Receiver
Update class documentation below.
Class TAO_ECG_CDR_Message_Sender
This could be eliminated if efficient reassembly // could be implemented without it. octet padding[4];
Member TAO_ECG_CDR_Message_Sender::send_message (const TAO_OutputCDR &cdr, const ACE_INET_Addr &addr)
Under some platforms, notably Linux, the fragmentation code in this method is woefully naive. The fragments are sent it a big burst, unfortunately, that can fill up the local kernel buffer before all the data is sent. In those circumstances some of the fragments are silently (gulp!) dropped by the kernel, check the documentation for sendto(2) specially the ENOBUFS error condition. There is no easy solution that I know off, except "pacing" the fragments, i.e. never sending more than a prescribed number of bytes per-second, sleeping before sending more or queueing them to send later via the reactor.
Class TAO_ECG_Mcast_Gateway
This class is an ACE_Service_Object, but the only reason for it is the need for easy configuration using files. Since ACE_Service_Object provides much more than that, we should look into replacing it with a more lightweight utility that would serve our needs.