[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Swarm-Support] Usage of Drop
From: |
Paul Johnson |
Subject: |
Re: [Swarm-Support] Usage of Drop |
Date: |
Thu, 06 Jan 2005 10:30:12 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 |
It is legal to call drop on yourself ([self drop]), but you have to be
very cautious if you do that. In the Swarm Sugar Scape example, they
avoid it by having objects report themselves to a reaper so they can be
cleaned out at the end of the step.
I have tried the immediate drop method and often run into segmentation
faults. Here are 2 reasons why.
1. Suppose agents are in a list. If one drops himself, but does not
remove all traces of himself from the system, then some other agent may
try to access that agent, and then finds nothing, and seg fault occurs.
2. Note vitally that the drop method returns void. Your object
overrides drop, and must return void. SO everything that has to happen
to clean up that object's memory has to happen first, before its
dropped. Cleaning up the memory while your code control is inside the
object itself is tough. It is cleaner to have some other agent (a
"reaper") tell the object "clean your memory" and then drop it with
[anObject drop]
I fought with this a lot in the arborgamesII code revisions last fall.
I wanted trees to burn and die right away, to immediately remove
themselves. I thought I had meticulously found all references to trees
and removed them, but it did not work.
Here's another drop related issue. In Swarm, the List collection is
slow at finding particular agents. If you want to drop a particular
agent, you go searching in that list, and it makes it slow. On the
other hand, if you write the model so that you are processing agents in
a list, and when you find one that needs to die, you have it in hand
and don't need to search, and you can move it into a list of agents
scheduled for death.
The only fast option is this relic, deprecated thing
"setIndedFromMemberLoc" that you find in some old swarm models. Its a
very non portable thing and we were talking about banning it altogether
in user applications, although I don't recall all of the problems with
it. It works by creating an instance variable in every agent that gives
that agent's position in the list. The arborgames code (original
version) used that alot. Because it was deprecated, I think I tried to
eliminate it in arborgames II
pj
Crile Doscher wrote:
Can an object call drop on itself, i.e. something along the lines of [self drop];? My gut
feeling is no but thought it might be useful to check. The context is that I have agents
that I'd like to drop once they reach a given set of coordinates - in my case, the agents
are water volumes that flow over and then out of simulation space and aren't needed
again. Wrap around is currently enforced so I'm looking into un-enforcing that but will still
need to drop them in some way. The agents are created in a ModelSwarm so I'm
assuming they'll have to be dropped from there, though I don't quite see the best way for
such an agent specific thing to bubble up to that next level. Thanks -
Crile
_______________________________________________
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