Re: Removing Actions

[Roger M. Burkhart]

>    This is probably a question for Roger.  I have a schedule of asynchronous
> events (set with at: time sendMessage to: etc.).  I keep the id that
> is returned with the function and later try to create an index so that I
> can remove it without doing the long remove (search whole list).
> The schedule allows a [remove member] but not an [index remove].  Is this
> not implemented?

Actually, since schedules inherit from Map, there is an [index remove]
that is implemented, but it doesn't yet have the right implementation to
remove actions correctly from a schedule.  For their own processing,
schedules create a special kind of index with extra logic to update
schedule structure correctly, but that's not the kind of index you'd get
right now with your own [schedule begin: aZone].

If you have your own index, this ought to work for now:
  [schedule remove: [scheduleIndex get]]

(Remove the action from the schedule, not through the index.)  Keep in
mind that the action at a given time could be a whole group of actions
scheduled at the same time, not any one of the individual actions you
originally put there (these are contained inside in the group of
concurrent actions at that time).  [aSchedule remove: anAction] removes
the action from whatever context it is currently included in.

> Also, after removing the action I try to "drop" it but neither dropFrom
> nor drop are recognized.  This is an "ActionTo_0.  How do I release the
> memory?

You're right that actions don't yet support a normal drop.  Action objects
ordinarily don't exist outside a schedule or other action plan; they're
allocated and controlled by the group to which they belong, and are
automatically freed from the same zone as the schedule when the schedule
itself maintains them (for example, by the AutoDrop option).

Probably a special form of drop that only works after an action has been
removed from a schedule is the proper way to handle this, but that's not
implemented yet.  For now, you may free the action using the low-level
message [aZone freeIVars:  anAction], where "aZone" *must* be the same
zone as the schedule in which the action was created.  But this is strictly
a temporary hack that you should expect to change to drop after it's
implemented.

Keep in mind when removing actions that it's still your responsibility to
make sure that the schedule's not currently processing the very same
action that you're removing.  As long as the schedule is either inactive
or currently executing any other action you should be all right.

This is another restriction that will be removed once the schedule's
dependence on underlying collections is cleaned up.  That's still on hold
for a collections revamp in progress.  The collections revamp will not
appear yet in the immediately upcoming release, but a whole lot of deeper
enabling change in class creation structure is included specifically to
lay the foundation for collections completion.

Dynamic maintainance of schedule structures is an important goal of Swarm,
so your probing of what works is quite valuable.  For the time being, please
try just to step around the lacunas remaining in implementation coverage.
It takes more time to finish each successive foundation layer in a
systematic way, but the result I think will end up solid.

Roger