Short: Better solution for the objectlist
Date: 990324
From: Lars, based on suggestions of Macbeth
Type: Feature
State: Acknowledged

The current handling of reset/cleanup/swapping is not bad, but still suffers
from the single-linked nature of the object list:
  - the whole list must be traversed to get rid of destructed objects
  - swapping can take time away from reset/heartbeats.

If one is willing to use a bit more memory on the list structure (skiplists
would come in handy), these problems can be solved. A better list structure
would allow to remove destructed objects on the spot, removing the need
to walk the entire list all the time.

During a commute home I came up with the following scenario. It's just
food for thought, but here it goes:

<ideas type="brainstorm">

All objects are member in up to three lists: one list for objects with
a heart beat, one list to organize 'events', ie. the calls to reset and
callouts, and one list for the swapper.

The heartbeat list is not sorted at all; the event list is sorted by the
time of the next event (callout or reset, whatever is earlier); and the
swapper list is sorted by the initial time-of-ref. This time-of-ref is
determined once when the object is inserted into the list and stays the
same even while the actual time-of-ref changes. This way the often
changes of the actual time-of-ref cause no excessive overhead.

During a backend cycle, the driver walks the heartbeat and event list
in parallel, calling objects which are due. Parallel so that heartbeats
and other events get an equal chance of execution. Afterwards, the user
commands are executed. Then, if there is some time left, objects can be reset,
cleant up and swapped.

<\ideas>