"future" is commonly used synchronization abstraction.It could be implemented in a library, using mutex, channel and interface.
Mutex needs not to be type-safe.And Mutex is not part of concept of "language tailored towards concurrency".
But "future" is well known, widely adopted (though, in different ways)concurrency primitive.It definitely has right to be part of "language for concurrency".
I've already implemented Futures as library code several times, but
they are redundant.To build Future as a library code, you need:- redundant interface{}- redundant Mutex- you still need 'chan'- you need to wrap it in a struct- and then provide "convenient" redundant api.
But 99% of functionality is already in 'chan' implementation.And ":= <-" with "<-" is a perfect api for future.There is a need only in a (relatively) small change to runtime and (abit larger) to compiler.
I missed the chance to comment on github...This also works for implementing futures and it's simple, type-safe and can be used with select:Of course the syntax is not as nice as built-in futures.
Go does not take a strong Erlang-like stance against concurrency with shared variables, so mutexes really are critical to Go's concurrency.
This is really a special case of the argument for generics in Go.Futures are to channels and stacks are to slices. With generics, you could provide first-class Future<T> and Stack<T>, but without generics it's simply not worth the effort for most users to bother with the abstraction since it can be written in little more than a dozen lines of code: https://play.golang.org/p/Obqag2hgZe It's just easier to implement the underlying operations directly.
Adding a new data type is not a small change to the language. It requires changes to the spec, the compiler, the reflect package, every program that uses the reflect package, every tool that manipulates Go source code, and many other things too. The only types that currently enjoy special status in the type system are slice, map, channel and a small number of others, all of which are very widely used.
понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь adon...@google.com написал:Go does not take a strong Erlang-like stance against concurrency with shared variables, so mutexes really are critical to Go's concurrency.Am I mistaken? Golang authors said mutexes are second class citizens.They'd prefer not to expose them, but unfortunately, channels are not fast enough for some use-cases.
Your code also misses the case when concurrently running goroutines wish to fill same future.
Most uses of reflect package doesn't bother with synchronization primitives. They only detects structs, strings, maps and slices, and ignores rest.Most of such code will not be broken.
> If you want to make it possible, it's pretty easy:
https://play.golang.org/p/YWYFSL2QTe
Thank you for fifth copy of almost same code. I clearly have no enough experience to use close of channel and `sync.Once`.
Do you really think so?
> There's another idiom I quite like for futures (when there's only one
possible source of the value) putting the value back after
taking it out: https://play.golang.org/p/_7p69KE_RZ
And that is really broken idiom. It has race condition: concurrent goroutine may put dufferent value in the channel between those two lines of code. More over, if you use blocking send here, then you will end in blocked goroutine in this case.
Another mistake in this idiom: if other concurrent goroutine checks this channel within select, and that check happens between those two lines (between receive and following send), then it see empty "future".
And even ir when does not lead to mistake, it serialize "broadcast": goroutines are awoken one after other, instead of being awoken in parallel.
That is why I want language (or standard library) to have reliable implementation: people should not invent bicycles with square wheels.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
--
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+unsubscribe@googlegroups.com.
Not all of them are wrong (in fact, almost none of them are). They just don't do everything and anything you could ever choose to want from an implementation so they appear unsatisfactory.Which, in the long list of issues that have been presented and remain unaddressed in regards to this proposal, adds another one: Writing one implementation that covers every use case you could ever have for them efficiently is, indeed, hard and error-prone. Whereas covering any specific use case with channels takes only a small handful of lines of trivial code.
On Tue, Oct 18, 2016 at 10:17 AM, andrey mirtchovski <mirtc...@gmail.com> wrote:
as a person happy to remain willingly ignorant of promises and futures
i notice from the sidelines that the concepts seem to lack clarity and
vision. if five different implementations got them wrong there will be
five different people wondering why the stdlib one isn't working
right. that's five too many.
On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura <funny....@gmail.com> wrote:
> Roger
>
>> If you want to make it possible, it's pretty easy:
> https://play.golang.org/p/YWYFSL2QTe
>
> Thank you for fifth copy of almost same code. I clearly have no enough experience to use close of channel and `sync.Once`.
> Do you really think so?
>
>> There's another idiom I quite like for futures (when there's only one
> possible source of the value) putting the value back after
> taking it out: https://play.golang.org/p/_7p69KE_RZ
>
> And that is really broken idiom. It has race condition: concurrent goroutine may put dufferent value in the channel between those two lines of code. More over, if you use blocking send here, then you will end in blocked goroutine in this case.
> Another mistake in this idiom: if other concurrent goroutine checks this channel within select, and that check happens between those two lines (between receive and following send), then it see empty "future".
> And even ir when does not lead to mistake, it serialize "broadcast": goroutines are awoken one after other, instead of being awoken in parallel.
>
> That is why I want language (or standard library) to have reliable implementation: people should not invent bicycles with square wheels.
>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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...@googlegroups.com.
On Tue, 18 Oct 2016 01:10:36 -0700 (PDT)
> email to golang-nuts+unsubscribe@googlegroups.com.
--
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+unsubscribe@googlegroups.com.
What Ian said, plus select is awkward to implement as a library, but works quite well when its syntax is analogous to switch.-rob
On Tue, Oct 18, 2016 at 11:41 AM, Ian Lance Taylor <ia...@golang.org> wrote:
On Tue, Oct 18, 2016 at 8:52 AM, <gop...@gardener.com> wrote:
> so why are channels and goroutines built into the language proper?
Channels and goroutines are widely used. Go does not follow a strict
principle of putting everything in a library. That said, ultimately
these things boil down to matters of taste, in this case the taste of
the original language designers.
Ian
> On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com wrote:
>>
>> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura 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
>>
>>
>> If it can be implemented as a library, why build it in to the language?
>> You don't need futures very often---far less than, say, Mutex, and mutexes
>> aren't built into the language either.
>>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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...@googlegroups.com.
Go does not take a strong Erlang-like stance against concurrency with shared variables, so mutexes really are critical to Go's concurrency.