>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> This could be a lot more efficient than modifying the vtbl and filling
>> up the stack with the keys. I really am suspicious of replacing the
>> vtbl entry, there may be more than one thread working its way through
>> the hash.
DS> Or have a "next" vtable function that takes a token and returns the next
DS> entry in the variable. Each iterator keeps its own "current token" and the
DS> variable's just responsible for figuring out what should get returned next.
DS> We could also have a "prev" entry to walk backwards, if we wanted.
The problem to be handled is how to modify the hash/array while the
iterator is live. (Multiple active iterators, in multiple threads.)
Even my versioning suggestion is problematic. We have the problem of
inconsistent views of the hash.
Even if iterator A only looks at version A (e.g. generation number).
What version should its changes apply toward? Or should we simply
make an iterator lock out access until completed?
How about this.
Iterators lock the hash upon the first access and release it when
either finished, reset or destroyed.
Your mechanism, is more like a seek,read,tell sequence without any
guarentees between access.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
