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 code. -- 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.
