[Bro] About IDs in MutableVals

Robin Sommer sommer at in.tum.de
Fri Dec 3 09:22:04 PST 2004


On Fri, Dec 03, 2004 at 15:49 +0000, Christian Kreibich wrote:

> Okay it's much clearer now, thanks! I guess what's still confusing me is
> why is this happening at the MutableVal level and not in Vals directly?

Basically it's just an optimization. We could just as well assign
global names to all values -- but we don't need to. A global name is
only required when a Val can actually be changed. If it can't, it
will never be referenced by one of the operations transfered during
synchronization (for example, an assignment to an integer always
creates a new Val and destroys the old one).

Optimizing even further, we need only assign global names to MutableVals
which are actually synchronized (or, in the future, persistent).

> I think this also comes back to the properties in MutableVals that I
> don't quite understand -- why are these not attributes?

Which kind of attributes are you refering to? (The term "attribute"
is quite is overloaded in Bro...). The attributes which are
associated with Vals are RecordVals which don't really fit here
(frankly, right now I can't remember what they are for... :-). The
attributes associated with IDs are more appropiate (and, in fact,
there are ATTR_SYNCHRONIZED/ATTR_PERSISTENT for IDs). But in
general, values contained in MutableVals are not bound to any ID.
Therefore, these attributes don't help for Vals.

Does this answer your question?

> right now I'm mass-murdering Bros whenever I send them

:-)

Robin

-- 
Robin Sommer * Room        01.08.055 * www.net.in.tum.de
TU Muenchen  * Phone (089) 289-18006 *  sommer at in.tum.de 



More information about the Bro mailing list