Konstantin No, no sync.Cond. Please, read links before writing answers. Please.
понедельник, 17 октября 2016 г., 17:12:42 UTC+3 пользователь Konstantin Khomoutov написал: > > On Sun, 16 Oct 2016 05:40:32 -0700 (PDT) > Sokolov Yura <funny....@gmail.com <javascript:>> 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.
