Serhat, imagine your feature in the context of a buffered channel that
holds 10 elements, and a writer go routine that wants to send 1000 elements
through that channel.
It is natural to imagine a downstream go routine reading and working on the
first element, and the writer filling the empty slot with #11 then being
blocked waiting to write #12.
But it is possible that the writer writes only #1, the reader reads it, the
channel is empty, and only later is #2 added to the channel, maybe when the
downstream go routine tries to read #2 and blocks, which might force the
runtime to continue the reader routine.
In this second case an outside observer would think "that channel is always
empty." It is unclear what meaning any instantaneous observation can have.
On Thu, Feb 21, 2019 at 12:20 PM Jan Mercl <0xj...@gmail.com> wrote:
> But then calling it or not has the exact same semantics. So what's it even
> good for?
>
> On Thu, Feb 21, 2019, 21:17 Serhat Şevki Dinçer <jfcga...@gmail.com>
> wrote:
>
>> btw waitempty(ch) does not return any value, and it does not (have to)
>> guarantee that ch stays empty when it returns..
>>
>>
>> On Thursday, February 21, 2019 at 11:10:45 PM UTC+3, Serhat Şevki Dinçer
>> wrote:
>>>
>>> Burak, I think you dont get the potential of the suggesred directives.
>>>
>>> You can be interested in waitepty(ch) for example when:
>>> - you have direct control of who is pushing and pulling on it, and you
>>> know what an empty buffer means
>>> buffer could be "things to do or process", and you have a very
>>> easy-to-setup observer to alert some routine that:
>>> - you are out of job, or
>>> - you have too many to process
>>>
>>> Also what you suggest as raciness is irrelevant:
>>>
>>> for {
>>> x := <- ch {
>>> // here, do you have a guarantee that you can put x back to the
>>> channel ??
>>> }
>>> }
>>>
>>> On Thursday, February 21, 2019 at 10:57:43 PM UTC+3, Burak Serdar wrote:
>>>>
>>>> You can implement waitempty(ch) without a race condition. However, any
>>>> scenario in which you use waitempty(ch) would have a race condition,
>>>> because the moment it returns there is no guarantee on the state of
>>>> the channel. So in a piece of code like this:
>>>>
>>>> waitempty(ch)
>>>> post
>>>>
>>>>
>>>> the only guarantee you have is that when 'post' is running, ch was
>>>> empty at least once since waitempty was called.
>>>>
>>>> This code:
>>>>
>>>> for {
>>>> if waitempty(ch) {
>>>> ...
>>>> }
>>>> }
>>>>
>>>> is racy, because when you go into the if block, you have no idea how
>>>> many times ch was empty.
>>>>
>>> --
>> 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.
>>
> --
>
> -j
>
> --
> 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.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
