Fixed that schedulers, which are not attached to an object, after
garbage collect were removed also from the scheduler dispatcher. The
scheduler dispatcher now attaches the schedulers to 2 different tables.
- A weak table ObjectSchedulers, which contains scheduler attached to
objects. When the object is removed, the scheduler is removed also.
- A weak table with PersistentSchedulers, which contains schedulers not
attached to objects. These schedulers are persistent, even after garbage
collection.
I hope this now makes the circle round...
The references of nillified and garbage collected SCHEDULERS are removed
from the _TIMERDISPATCHER. This results now in schedules that are still
pending to be executed, but are nillified, that these schedules will
never be executed!!!
Sven
So, when the Scheduler that is passed to the AddScheduler is nillified,
the internal arrays that keep the Scheduler reference are also
nillified. And it does what i need for further utilization in MOOSE
classes. When the Scheduler is nillified, but, a schedule was planned
for that Scheduler, once the scheduler fires off, it will ignore that
call... cool.
Sven
It is working now, and NOW SWITCHING SLOTS of PLAYERS ALSO WORKS IN
TASKING!!!
Jippie!!!
The next thing is to debug the DETECTION_DISPATCHER...
And make STATEMACHINE_TEMPLATE now as a parameter to create new
STATEMACHINEs, instead of that ugly table construction.
The, I need to modify the New: Methods of each STATEMACHINE_PROCESS to
be initialized with a TEMPLATE... Maybe I can commit already and just
implement this later ...
- Caching the menus on the GROUP object.
- When a new menu is created, it will chech the cache
- When the menu is already in the cache, nothing will be done and the
self is returned.
- When the menu is not in the cache, the menu is created and the cache
is updated.
- The removal of menus now work flawlessly, because the cache is now
used to traverse the path of submenus during removal.
Reworked the hierarchical state machine processing in terms of sub
processing.
Now, the declaration and usage of subs is completely understandable and
easy to implement.
I am excited to see how end-users will see the possibilities.
FlightControl