Re: [Wipsim-devel] Addition to cActive for AlreadyScheduled and ScheduleInPast

[Gerben K. <gk...@ko...>]

On Mon, 15 Dec 2003, Martijn Kuipers wrote:

> On Mon, 2003-12-15 at 15:34, Gerben Kuijpers wrote:
> > Hi,
> >
> > Currently, the scheduler will give a general warning when an event is
> > scheduled with a delay < 0 or when trying to schedule an event that is
> > already scheduled. No information is provided about the specific event.
> > Extra information will speed up debugging. This can be done in different
> > ways:
> >
> > 1. An event-ID can be added to each event, with a unique identifier for
> > each event, so the scheduler can output which event caused a scheduling
> > problem. However, this means that more memory is used by each event and
> > specially for small active classes, this might be unacceptable.
> I was also thinking about adding a name/identifier for each class (as a
> static) so we can identify classes. This way if we get an
> assertion-failure or other weird error, we can produce adequate
> information where to look.
Ofcourse it is also possible to combine this with the extra function
(option 2). The identifier can then be outputted by the error-function.

>
> > 2. Add two virtual functions to cActive (one for AlreadyScheduled and one
> > for ScheduledInPast). By default these functions are empty, but each
> > derived class that wants to add additional information can re-implement
> > the functions and add as much information as needed. The functions only
> > take up space once per active class and not per instance.
> How about a debug function, which prints out all kind of information of
> the class. The scheduler can easy say if it was because of prior
> scheduling or scheduling in the past
So, first the scheduler outputs some error and then calls the Debug
function of the active class?


>
> > My preference is for option 2, since it is easy to extend and does not
> > require any significant changes to the simulator. What do you think?
> >
> We used to have a reason that a class can only be scheduled once. This
> so at a later time it will not be scheduled before the already scheduled
> item.
> I am inclined to have an extra identifier in the active class which
> tells you if the class has to be scheduled uniquely or can be scheduled
> more than once. There are a number of events which can be easily
> scheduled more than once (source application is one).
I think we should be very careful with this. So far, the errors from the
scheduler have helped me to avoid some nasty bugs. Scheduling more than
once should only be used if really necessary. For a source application,
the next event can just as easily be scheduled in the current event
function. Scheduling each class only once will also reduce the memory
usage of the scheduler.

> /Martijn
> P.S. I have reworked sniffing quite a bit and added a log-file. We can
> now even print to the logfile from anywhere in the code also to aide in
> debugging. I hope to give you a sneak-peek this week (I started with the
> 802.11 mac and it looks pretty clean with th enew sniffing :-)
Nice!

/Gerben