Re: rescheduling

[Marcus G. Daniels]

>>>>> "WS" == William S Shu <address@hidden> writes:

WS> A Suggestion: it seems one can actually define the number of
WS> simulation (time) steps in a Batch swarm run.  Can this not be
WS> modified so that one can dynamically change the number of
WS> simulation steps (for selected swarms) to zero, even for
WS> interactive swarms?

Sorry, I don't understand what you mean here.

WS> a) How does one "break into" the scheduling cycle of a given swarm, and
WS> possibly reorganises it and ... gets away with it?

You can add items to any agent schedule and get away it.  Removal
should be via the remove: per the code example.

WS>  b) When an
WS> object is dropped, in which scheduling time-step are other objects
WS> (possibly in different swarms) notified?

There is a direct code path from -drop to the notify function.
The same time step.

WS> Intuitively, one may simply say "respond only to the first of
WS> multiple calls of an addRef:withArgument: message, and ignore all
WS> but the first of the matching removeRef: messages".  But this
WS> would not necessarily do, if these messages where used to
WS> synchronise *specific* code fragments, or mutually exclude entry
WS> into them.

All objects have a list that holds all the notify functions added with
addRef:withArgument.  These are all called before the object is deallocated,
and the references disappear.

WS> Still on the addRef:withArgument: message, notification is done
WS> everytime an object changes.  This probably causes high runtime
WS> overheads. 

Notification is only done when an object is dropped.  There's the
variable for reallocation in the interface, but that doesn't actually
do anything.  

Since you mentioned it, I think that it could be useful to be able to
configure write barriers for objects.  Using popular memory management
hardware interfaces (e.g. mprotect), one can throw exceptions
(actually trap segfaults) when the physical memory associated with
some object is touched.  This could be an efficient way to update
asynchronous probe Java applets.  One extreme would be to completely
eliminate ObserverSwarms and to attach all instrumentation via shared
memory (Swarms are associated with Zones, and Zones have all the
memory allocation metadata).  Perhaps there could be a selectable
buffer size that would ship off N events blocks, for more efficiency.

WS> (NOTE: I am not advocating for an operating system to be built
WS> into swarm!)

How about building an operating system out of Swarm?
Say, with http://www.cs.utah.edu/projects/flux?


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.