As others have said, such operations are inherently racy - when you receive
the message that a channel is empty, it may not be empty any more. For that
reason, it's not a good idea to add them as primitives to the language.
That said, it's not too hard to implement them yourself. We are talking
about buffered channels here, so an extra item being buffered should be OK.
So you can insert a goroutine in between sender and receiver that signals
when it can't receive on a channel (it's empty) or when it can't send on a
channel (it's full).
Here's some code that implements those operations:
https://play.golang.org/p/2xyZnUI0imX
Note that there are many other possible variants. For example, you might
want to send on the notification channel only when the channel has been
idle for some time.
cheers,
rog.
On Thu, 21 Feb 2019 at 13:38, Serhat Şevki Dinçer <jfcga...@gmail.com>
wrote:
> Hi,
>
> Say you have a buffered channel
> ch := make(chan int, 10)
>
> Would it make sense and be easy to add the following directives to the Go
> language core?
>
> waitempty(ch)
> blocks caller until ch buffer is empty
>
> waitfull(ch)
> blocks caller until ch buffer is full
>
> This means there are 3 types of goroutines related to a channel:
> - senders
> - receivers
> - observers
>
> There are nice possibilities with these, for example wait groups, resource
> usage alerts etc.
>
> What do you think?
>
> --
> 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.
>
--
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.
