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

[martijn cox]

Thanks for both your answers!
After trying to implement Pauls scheme, it turned out the problem still
existed: the id to the dropped agent didn't point to nil (from what I recall
from gdb it pointed to 0xfffffe or something otherwise evil-looking). After
some thought, and reading Kens answer this made sense because the pointer to
the voided agent never got reset to nil, so it isn't detectably pointing to
a voided object...
The bullseye solution was kindly provided by Ken's 'option A'. I had
allready noticed and thought about using the -remove operator for schedules,
but through some miracle of denseness I figured it wasn't applicable in this
case. Silly me, of course it *was exactly* what I was asking for in my
original post.

Thanks again for your help, much appreciated!

Martijn

----- Original Message ----- 
From: "Ken Cline" <address@hidden>
To: "Swarm Support" <address@hidden>
Sent: Monday, August 01, 2005 9:39 PM
Subject: Re: [Swarm-Support] How to prevent sending a message to a
droppedobject?


> 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
>
>