[Ns-developers] ns-3 and future development

[Tom Henderson]

>-----Original Message-----
>From: Mathieu Lacage [mailto:Mathieu.Lacage at sophia.inria.fr]
>Sent: Tuesday, January 17, 2006 04:14 PM
>To: 'Tom Henderson'
>Cc: 'ns-developers'
>Subject: Re: [Ns-developers] ns-3 and future development
>
>
>I did spend a bit of time thinking more about this API. Would you be
>okay with something like this:
>
>event-cancellable.h:
>class EventCancellable: public Event {
>public:
>	EventCancellable () 
>	: m_state (INITIAL) {}
>
>	bool is_canceled (void) {
>		return (m_state == CANCEL)?true:false;
>	}
>	void cancel (void) {
>		assert (m_state == INITIAL);
>		m_state = CANCEL;
>	}
>private
>	typedef {
>		INITIAL = 0,
>		CANCEL  = 1,
>		DEAD    = 2
>	};
>	virtual void notify (void) {
>		assert (m_state != DEAD);
>		if (!m_canceled) {
>			do_notify ();
>		}
>		delete this;
>	}
>	~EventCancellable () {
>		m_state = DEAD;
>	}
>	virtual void do_notify (void) = 0;
>	uint8_t m_state : 2;
>};
>
>and event-cancellable.tcc which defines a bunch of
>make_cancellable_event () functions
>
>This API is maybe a bit too simplistic. What do you think ?
>

What is your rationale for abandoning the name "Timer" in favor of "EventCancellable"?  Can't we just define Timer as a cancellable Event (your previous message had class Timer : public Event)?  In perusing the ns-2 source, all events are cancellable, but it seems that only timers actually make use of the function.

Also, as far as implementation goes, it seems in ns-2 that cancelling an event requires to go into the scheduler and find it.  I wonder whether it will be more efficient to avoid how ns-2 does it and just flag the event as cancelled, and stay out of traversing the list/heap.  I don't know whether this will significantly increase the average number of events in the scheduler, impacting other operations such as ordered insert.  Has anyone studied this tradeoff?

Current ns-2 has resched(delay) and differentiates from IDLE(INITIAL) and PENDING(i.e., RUNNING) states.  

Tom