Re: rescheduling

[William S. Shu]

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


In the HeatbugBatchSwarm.h we find:

        ...
        @interface HeatbugBatchSwarm : Swarm {

          int loggingFrequency ;            // Frequency of fileI/O

          int experimentDuration ;                        // When to Stop
the Sim
        ...

which I took to be parameters needed by the swarm.  I hope I have not read
too much into these variables (and comments!).

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


Does this mean if I used addRef:withArgument THRICE with the same
(identical) receiver and arguments, as in:

  [obj->targetObject addRef: notifyFunction withArgument: obj];
  [obj->targetObject addRef: notifyFunction withArgument: obj];
  [obj->targetObject addRef: notifyFunction withArgument: obj];

the same object will be called THRICE before being deallocated by drop?  (I
would be more at ease if this is the case!)

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


This seems to be at variance with the docs.  From the docs, I had the
impression notification would be done even for assignments to the objects!

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

Sounds a brilliant idea.



William.



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