Re: [Swarm-Support] How to prevent sending a message to a dropped object?

[Ken Cline]

I'm not sure that will work in Martijn's situation[1]...  If the
'mother' pointer is valid when it is passed as an argument to the
'considerChildbirth' message then it will be non-nil when the
action occurs and the message is sent to the model swarm, right?
If so, then the 'if (mother)' test will not detect that the pointer
is a handle for a dropped object, correct?

In any case, as far as I understand it, there are 2 basic ways to
handle the bookkeeping issue that Martijn has:
  A. Agents take responsibility for their actions (no passing the
     buck!).  That is, the agent maintains a handle to the Action
     objects created and returned by the Schedule and, when the
     agent is being dropped, all its pending actions are also
     dropped.  I think all you need to do is call [Schedule
     remove: anAction].

  B. Agents are managed in a data structure and actions are invoked
     on that structure instead of directly on the agent.  The
     data structure could be the model swarm, as suggested, or
     lists or maps that it maintains.  The data structure must
     keep a registry of who is alive or dead and then either
     execute or ignore any the requested action as appropriate.
     That is, just what Paul has shown except that you'd test
     if the mother ID was in your "obituary" list.

I think either approach is acceptable; both have pros and cons.
And there are hybrid designs as well, e.g. the model swarm could
maintain a data structure that maps agent IDs with handles to
their Action objects and does the schedule clean up on behalf to
agent and its grieving family.

Note, there may be other reasons for maintaining agents in
cryostatis, e.g. for calculating statistics at the end of a
simulation.

Btw, another approach, which is perhaps a little more technically
challenging, would be to extend the Swarm framework.  For example,
you could define a protocol called MortalAgent and create a subclass
of Schedule.   Your subclass of Schedule would understand that when
an Action to a MortalAgent is created that it, the subclass Schedule,
should store the necessary bookkeeping information to remove all of
that agent's actions when it dies.  There are merits to this design
as well, e.g. the agent code becomes much simpler and the Schedule
subclass may be able to implement efficiencies that the agent object
can not.  However, I suspect that it would take a fairly deep under-
standing of the Swarm libraries to implement this approach.  Maybe
not, though?

My $0.02.  Hope that helps.
Ken

PS: There are many things other than schedules/actions that can
    hold onto pointers to dropped agents, e.g. probes, UI widgets,
    and etc, and hence could cause segmentation faults.  It's
    amazing how many lives a simple agent can touch.
____________
[1] My apologies if I'm wrong about this.  I'm not actively doing
    and C or Objective-C programming (not much programming at all,
    in fact) and so I'm a little rusty on this stuff.

--- Paul Johnson <address@hidden> wrote:

> I think I'd redesign it so that dead mothers were never sent messages. 
> That is, remove the dead ones from the lists being processed.
> 
> But I think you can brute force fix this like so. Instead of having this 
> message put "haveChild" with target "mother__" on schedule, have it aime 
> the message at something you are sure exists, say model swarm.
> 
> [lifeMutationSchedulw at: (time + (int) (0.25* DPY*MPD)) createActionTo: 
> self message: M(considerChildbirth):mother];
> 
> 
> Then in that method
> 
> (void)considerChildbirth: mother
> {
>     if (mother) [mother haveChild];
>     else fprintf(stderr,"you just tried to give birth from the dead, 
> silly!");
> }
> 
> If "mother" is a pointer to nil, then this will prevent the seg fault.
> 
> Won't it?
> 
> pj
> 
> martijn cox wrote:
> > Hi,
> > 
> > Im new here so if I break any form of etiquette, please forgive me :)
> > 
> > I've been working on a (very simple) swarm-based simulation of evolution,
> > and have come accross the following problem. Female animals can have
> babies,
> > after impregnation by a male. This impregnation is a combining of the
> neural
> > networks of the parents, and this new neural network is stored in the
> > female. during here. During her pregnancy, the female can die, and carry
> her
> > unborn child with her (*sob*).
> > 
> > The problem is, that I'd like to have the pregnancy scheduled by the model
> > by the following ActionCreateTo:
> > --------------------------------------------
> > -scheduleBirthFromMother: (id) mother__
> > {
> > *snip*
> > [lifeMutationSchedule at: (time + (int) ( 0.25 * DAYSPERYEAR *
> > MINUTESPERDAY ))
> >    createActionTo: mother__
> >    message: M(haveChild)];
> > *snip*
> > }
> > --------------------------------------------
> > and if the female dies somewhere between impregnation and giving birth,
> this
> > message is send to a voided reference (because the female has long and gone
> > been dispatched of by a reaperQueue).
> > The final result is that every call subsequent call to create sends my
> > program crashing to its segmentation faulty damnedness, I presume because a
> > method has been called on with self = nil and as a consequence, the stack
> > has become corrupt.
> > 
> > A short term solution I've been using so far, is to not wipe the
> > reaperqueue, but keep all agents in cryostatis for the length of the
> > simulation (so the speak). Another solution would be to undo the
> > ActionCreateTo, but I see no way in all documentation I've searched through
> > how this can be done.
> > 
> > If no one can help me, I will probably resort to waiting untill after the
> > message has been sent to the dead agent before I wipe it from memory, but I
> > don't think that would be a very clean solution.
> > 
> > Kind regards,
> > 
> > Martijn Cox
> > 
> > ps: my gratitude for supplying the incredibly usefull environment to anyone
> > who has ever contributed to swarm! :)
> > _______________________________________________
> > Support mailing list
> > address@hidden
> > http://www.swarm.org/mailman/listinfo/support
> 
> 
> -- 
> Paul E. Johnson                       email: address@hidden
> Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
> 1541 Lilac Lane, Rm 504
> University of Kansas                  Office: (785) 864-9086
> Lawrence, Kansas 66044-3177           FAX: (785) 864-5700
> _______________________________________________
> Support mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/support
> 



_________________________________________________________
 Ken Cline                             W: (443) 287-2636
 address@hidden