> What you are doing is what sync.Once was invented for: Uh-huh. Once is similar but slightly more primitive than a future, since the thunk is passed explicitly to the Do() method instead of being stored in the future itself.
> https://play.golang.org/p/erZqwFYgIR I think there's a bug in your code: you retain f.thunk, hence any values the thunk closes over won't be garbage collected as long as the future itself is retained. (Which might be an argument in favour of having futures in a library, they're not completely trivial to implement correctly.) Your idea turns out to be very slightly slower than my AtomicFuture, probably due to the unconditional call to Once.Do() in the fast path. But the code is much cleaner -- the ugly double checking is encapsulated within the Once. BenchmarkMutexFuture 50000000 22.1 ns/op BenchmarkMutexFuture-2 30000000 40.1 ns/op BenchmarkMutexFuture-4 20000000 86.2 ns/op BenchmarkAtomicFuture 200000000 6.92 ns/op BenchmarkAtomicFuture-2 500000000 3.68 ns/op BenchmarkAtomicFuture-4 1000000000 2.82 ns/op BenchmarkChannelFuture 50000000 29.5 ns/op BenchmarkChannelFuture-2 30000000 54.5 ns/op BenchmarkChannelFuture-4 20000000 64.6 ns/op BenchmarkOnceFuture 200000000 8.54 ns/op BenchmarkOnceFuture-2 300000000 4.52 ns/op BenchmarkOnceFuture-4 300000000 4.04 ns/op -- Juliusz -- 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. For more options, visit https://groups.google.com/d/optout.
