FAQ
I'm iterating through map entries, and occasionally, I delete the key I'm
currently on. That is:

for addr, shutdown := range children {
if shouldShutdown(addr) {
close(shutdown)
del(children[addr])
}
}

The spec at http://golang.org/ref/spec#For_statements states that deleting
entries not already iterated over is safe, and behaves as you'd expect.
However, unless I missed it, it doesn't state whether or not it is safe to
delete the current entry, as I do above.

Given Go's sensible design, I'm guessing that it was a property too trivial
to state, but C++ has made me paranoid about how iterators react to
mutation.

So, is the above defined behavior? If so, would it be worth explicitly
pointing out in the spec?

- Dave

--

Search Discussions

  • Jan Mercl at Nov 4, 2012 at 10:29 pm
    It's implied from the fact that every key is visited only once. While
    deleting a non visited key is defined to be safe explicitly, deleting
    an already visited has no effect on the iteration b/c the key was
    already seen.

    -j
    On Sun, Nov 4, 2012 at 10:55 PM, David Anderson wrote:
    I'm iterating through map entries, and occasionally, I delete the key I'm
    currently on. That is:

    for addr, shutdown := range children {
    if shouldShutdown(addr) {
    close(shutdown)
    del(children[addr])
    }
    }

    The spec at http://golang.org/ref/spec#For_statements states that deleting
    entries not already iterated over is safe, and behaves as you'd expect.
    However, unless I missed it, it doesn't state whether or not it is safe to
    delete the current entry, as I do above.

    Given Go's sensible design, I'm guessing that it was a property too trivial
    to state, but C++ has made me paranoid about how iterators react to
    mutation.

    So, is the above defined behavior? If so, would it be worth explicitly
    pointing out in the spec?

    - Dave

    --
    --
  • Kevin Gillette at Nov 5, 2012 at 4:50 am

    On Sunday, November 4, 2012 3:29:34 PM UTC-7, Jan Mercl wrote:

    It's implied from the fact that every key is visited only once. While
    deleting a non visited key is defined to be safe explicitly, deleting
    an already visited has no effect on the iteration b/c the key was
    already seen.
    In that case, the spec may benefit by being amended with a phrase along the
    lines of:

    Any mutation of the map during iteration, by the iterating goroutine or in
    synchronization with the iteration, is safe.

    --
  • Jan Mercl at Nov 5, 2012 at 9:08 am

    On Mon, Nov 5, 2012 at 5:50 AM, Kevin Gillette wrote:
    Any mutation of the map during iteration, by the iterating goroutine or in
    synchronization with the iteration, is safe.
    That's problematic. Consider http://play.golang.org/p/kc38uNdmsK vs
    http://play.golang.org/p/5XJER_DOTA

    Both programs behave perfectly per specs, but I would not call such
    mutation "safe" as it produces unpredictable results.

    -j

    --
  • Si guy at Nov 5, 2012 at 11:24 am
    Wow, that looks like fun.

    Still memory safe though right? I mean, if your app is agnostic to this odd behaviour.

    --
  • Kevin Gillette at Nov 5, 2012 at 11:58 am
    I'll clarify "safe" to be safe from memory/data-struct corruption, if
    that's true. There are implementations for other languages in which
    iteration over a map-like object will de-sync the 'iterator' and leave its
    pointer dangling -- their usual fix is to include some kind of ismodified
    flag or generation, and have the iterator abort if it detects an
    out-of-sync condition.

    Some programmers coming to Go will want to be explicitly told that they
    can't segfault their app by modifying a map whilst iterating over it.
    On Monday, November 5, 2012 2:08:28 AM UTC-7, Jan Mercl wrote:

    On Mon, Nov 5, 2012 at 5:50 AM, Kevin Gillette
    <extempor...@gmail.com <javascript:>> wrote:
    Any mutation of the map during iteration, by the iterating goroutine or in
    synchronization with the iteration, is safe.
    That's problematic. Consider http://play.golang.org/p/kc38uNdmsK vs
    http://play.golang.org/p/5XJER_DOTA

    Both programs behave perfectly per specs, but I would not call such
    mutation "safe" as it produces unpredictable results.

    -j
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 4, '12 at 9:56p
activeNov 5, '12 at 11:58a
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase