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

[martijn cox]

Well, that would indeed work, but the thing is: I don't have the pointer to
the object available. All I can do is loop over a List of agents like so:

 while( (agent = [index next]) != nil )
    {
      if ([agent getBirthAction])
       [lifeMutationSchedule remove: [agent getBirthAction]];
      [_agentList remove: agent];
      [agent drop];
      agent = nil; // ***
    }

and then it makes no sense to do the reset at ***, since that isn't the
pointer that will be passed when I use the agent as an argument to a method.
I don't know where to get the actual pointer. I might be self? or perhaps
there is some other, lower level pointer that is used for this..


----- Original Message ----- 
From: "Paul Johnson" <address@hidden>
To: "Swarm Support" <address@hidden>
Sent: Tuesday, August 02, 2005 9:16 PM
Subject: Re: [Swarm-Support] How to prevent sending a message toa
droppedobject?


> martijn cox wrote:
> > 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...
>
> What if you set the object to nil after it is dropped? I was assuming
> your dropping process had
>
> [anObj drop];
> anObj=nil;
>
> Then wouldn't that get it?
>
> > 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
> >>
> >>
> >
> > _______________________________________________
> > 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
>
>