Good point, simple examples are almost never enough. I guess I was hoping
that we'd end up with 3-5 examples of a really simple case. Maybe I'll come
up with a more complex example.
I'm loading under ~5K files in parallel and possibly making an HTTP request
for each. I like the slice solution,
On Sunday, October 15, 2017 at 1:45:06 PM UTC-4, Alex Buchanan wrote:
>
> Show me the code! :)
>
> Here's mine: https://play.golang.org/p/ZwAlu5VuYr
>
The problem that sync.Map is intended to address is cache contention.
Unfortunately, it doesn't currently address that problem well for stores of
Show me the code! :)
Here's mine: https://play.golang.org/p/ZwAlu5VuYr
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
An added advantage of a channel solution is that it is far easier to reason
about from a correctness point of view. And it needs less information
transfer on the side for human beings. Don't underestimate the power of a
solution which is easily picked up by later readers of the code base.
On Sun,
Like Mr Pryczek, I'd be concerned that
- the performance will be pessimized for this case, and
- the approach is un-go-ish.
Share memory by communicating is a Go idiom: send updates to a goroutine
via a pipe, and by construction let the map never be written by others.
It's more work to think ab
So many good answers! Lots of different ways to accomplish this. I'll say
that in this specific case, which is does not require every ounce of
performance, syncmap is by far the simplest and least amount of code, so
readability wins on this one.
--
You received this message because you are sub
I think using standard sync'ed map may be bad idea for this use case
(write-only access), especially taking into account that it's optimized for
read access and stable keys, so each write will acquire mutex anyway.
if nothing is read from that map during the threads run, it should be
probably m
