On Sun, 16 Oct 2016 05:40:32 -0700 (PDT)
Sokolov Yura <funny.fal...@gmail.com> wrote:

> "future" is commonly used synchronization abstraction.
> It could be implemented in a library, using mutex, channel and
> interface. Example:
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value.
> And "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
> So I propose to introduce "future" as a same internal type as a
> "channel". It will share representation and lot of code with buffered
> channel (of capacity 1).
> https://github.com/golang/go/issues/17466

If I'm not mistaken, you propose to implement some abstraction atop of
the existing sync.Cond type.

I'm not sure this is needed: a library implementing a "future" type
will be like 50 lines of code -- basically combining a variable of type
sync.Cond with a variable of type interface{} plus small amount of glue

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.

Reply via email to