At 05:17 PM 9/5/00 -0400, Chaim Frenkel wrote:
> >>>>> "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.
We punt. If the programmer wants consistent data in a multithreaded
program, he or she needs to lock the hash down. I'm all up for the
iterators looking at the hash as it exists--if the programmer wants a
snapshot of the hash keys or values, they can flatten them down to a list
or not mess with the hash in ways that'll geek the iterator. I don't see
any real reason that multiple iterators should behave any differently than
the single one we have now in that respect.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
