Question: anyone still online? :smile:

Asked By
g_questions
Asked At
2017-08-20 00:27:40

Found 15 possible answers.

User Answered At Possible Answer
aniskywalker 2017-08-20 00:27:53 Yep.
g_questions 2017-08-20 01:19:00 hey guys Any vim user still online? :stuck_out_tongue:
aniskywalker 2017-08-20 01:40:07 I have the weirdest issue right now. I’m trying to write a benchmark for a delete function. It’s going fine and dandy until I hit some random number, at which point a map returns nil for a value that I can observe through the Gogland debugger should not be nil. I wonder if this has to do with reflect.TypeOf… to the naked eye the type looks exactly the same, but anything’s possible. Which, if you use a debugger to examine the state at the time of the panic, is just not true. If you run the Delete benchmark, it will fail at some random point because seg is nil. https://github.com/20zinnm/go-polymorphic I’ll post the code in a moment. There doesn’t seem to be a pattern to which time it returns nil.
200sc 2017-08-20 01:45:01 I'm not sure b.N is guaranteed to be the same if you loop over it twice. I'd have to check though.
aniskywalker 2017-08-20 01:45:37 So the idea was that I pre-fill the container with enough things so that the benchmark isn’t just measuring the insertion cost. So each time b.N changes I pre-fill more values into the container. My impression of benchmarking was that it would re-call the whole benchmark function for each trial and change b.N each time, right?
200sc 2017-08-20 01:47:03 Maybe. I'll check out running the code in a second.
aniskywalker 2017-08-20 01:47:16 Hm, might’ve found my issue. OK so somehow there is a nil index which is getting returned. Which means it has to do with either how my benchmark was written, which is pretty straightforward--make an array of indices to delete and then delete them--or how I allocate indices. For some reason the index’s type is nil here. So the issue has to do with indexes and not the segment itself.
200sc 2017-08-20 01:51:32 It doesn't crash for me.
shawnps 2017-08-20 01:52:03 @aniskywalker think you have a data race
aniskywalker 2017-08-20 01:52:08 Yeah, I think so too.
shawnps 2017-08-20 01:52:13 (not sure if related to this issue) try this: go test -bench=BenchmarkContainer_Delete -race
aniskywalker 2017-08-20 01:52:23 Indexmanager is racing
200sc 2017-08-20 01:53:02 It also performs very differently if you run all of the tests vs just Delete
shawnps 2017-08-20 01:53:03 c.Unlock is called to early i think nvm. moving that didn’t fix it
aniskywalker 2017-08-20 01:53:28 Yeah the lock is for the map go slices are not concurrent-writeable I see Oh wait a minute And there should only be one for any container Now I’m not sure why indexManager is a race condition--it’s the same algorithm as the segment routine.

Related Questions