Re: [go-nuts] An old problem: lack of priority select cases
On Thursday, September 12, 2019 at 11:22:35 AM UTC-4, trishc...@gmail.com wrote: > > Why not just set up priority blockers against the one What does priority blockers mean? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5f620a25-a37e-491c-87b4-cc49342af22e%40googlegroups.com.
Re: [go-nuts] An old problem: lack of priority select cases
Why not just set up priority blockers against the one -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5976581c-260b-4ba2-be02-b87403a1fec8%40googlegroups.com.
Re: [go-nuts] An old problem: lack of priority select cases
No, please review this: https://play.golang.org/p/sPWrNhzRXKz There is no need to use the lock in Read()Encapsulation in this case means, the user of MultiWriterIntChan does not know it uses locks behind the scenes, nor does it need to know.Due to limitations of the playground, the code referenced above runs serially. The sleeps are ONLY in there to demonstrate that early termination works - they are not needed for correctness.That the writer does not unlock unless the channel is read is a limitation of unbuffered channels in Go - you could get around this by using a select and default. Closing a channel with waiting writers will cause a panic. Your technique is incorrect in my mind because...The Close() will read from the channel, causing other writes - that the Producer thought were processed to be discarded. This is incorrect behavior in most use cases (think if the Producer was generating log messages).For the version I posted, every write that completes will be handled by a consumer.-Original Message- From: Leo Lara Sent: Sep 4, 2019 8:24 AM To: Robert Engels Cc: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases By encapsulation? Are you talking about https://play.golang.org/p/YOwuYFiqtlf or other version of the code?As I think someone already said, there is a need in the method Read for a lock. And the read from the channel is done from that method. With your pattern, the user of the hypothetical component reading from the channel needs to hold a lock.Perhaps you do not need to check of c.closed as the closed channel with signal it already with the "ok" result. In that case you wouldn't need a lock in the reader, and it would be transparent for the reader.Another drawback of this implementations is that the writer does not unlock unless the channel is read. Perhaps in some situations this does not matter, but this also implies that the Close method will not exit until they are read, plus the problem of not being fair, that new writer goroutines could go forward while Close is blocked in the Write mutex, as you block writing on a channel while holding a read lock that increases the chances of unfairness trying to get the write lock. This is a smaller problem in mine as the lock is hold for much shorter time, and I do not block inside the read lock.I have seen several alternatives here, but still not a critisism of why those implementations would be preferable over mine. The only thing I see in the alternatives is that they combine less different concurrent idioms. Mine needs a lock, a waitgroup and "closing" channel but it seems to have better external qualities: transparency, fairness, performance, writer can spawn any time...On Wed, Sep 4, 2019 at 1:22 PM Robert Engels <reng...@ix.netcom.com> wrote:As for the readers being aware of a lock, that is not true either, as the lock is hidden by encapsulation. (The last and best version doesn’t even need the lock on the readers)On Sep 4, 2019, at 4:55 AM, Leo Lara <l...@leopoldolara.com> wrote: You should read up on how a RWLock works.I am not going to answer to that ;-)About this code:https://play.golang.org/p/YOwuYFiqtlf1. I wouldn't say that there are several goroutines writing, as there are several goroutines block in a mutex. Some might find this not important, although there are some people that have looked into this and think it is less efficient https://opensource.com/article/18/7/locks-versus-channels-concurrent-go ; I think it has to do on how the scheduler changes to another goroutine when the goroutine is lock on a channel.2. More importantly IMHO, in your example the reader has to be aware that there is a lock. Hence, it is not "transparent" in the sense that the reader has to share something with the writer The Sleep(1) in the producer is only to add some delay to demonstrate it gets terminated before the desired number of iterations. On Aug 29, 2019, at 12:13 AM, Leo Lara <l...@leopoldolara.com> wrote:Hi Robert,To put you in context, it all started when I read https://go101.org/article/channel-closing.html , that said that it is impossible or at least you shouldn't close a channel that is being written by several goroutines. Then I wrote this article with my solution https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 also in https://medium.com/@leolara/closing-a-go-channel-written-by-several-goroutines-eba3a6c9404b I then created this issue https://github.com/go101/go101/issues/132 and from there this topic was created by T L.Your example does not have several goruitnes writing so I think it is a different problem. Perhaps that simple lock would work with several goroutines, but I think there would be more contention with this lock.Anyway, I think I have already an optimisation to my code, I think using a RW lock, if I put the "Add(1)" in a read lock and the wait in a Write lock it might work better. The race co
Re: [go-nuts] An old problem: lack of priority select cases
>>>
>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux
>>> wrote:
>>>
>>> One should also be careful regarding the conceptual demands he or she is
>>> making.
>>> Having a shared resource (that is complex enough that it cannot be
>>> atomically accessed or modified) means essentially that "having multiple
>>> writers being transparent to the readers", fundamentally, is not possible.
>>>
>>> From the moment itself when such a resource is shared, there must be
>>> some sort of mecanism (that one using resources atomically usable) that
>>> ensures the integrity of it.
>>> Maybe what you're talking about is having it transparent in terms of
>>> code, in which case we both agree, but if you're looking for something
>>> transparent in essence, as in performance, logical construction and all the
>>> rest, I think there is a misunderstanding here: even if it was added in the
>>> language, there would be many many things going on under the hood, as it is
>>> already (and cannot really be otherwise) for channel use alone.
>>>
>>> As for the priority using selects, I think it's more of something to be
>>> dealt with on the "user-side". There are many kinds of priority in general,
>>> and trying to implement something in the language itself would IMO either
>>> be too specific compared to the nessecary time to do so or it would
>>> probably have a huge overhead on the "classical' use case of the select
>>> construct.
>>> + the fact that it is apparently already possible using RWMutexes.
>>>
>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz a
>>> écrit :
>>>
>>>> Think of a channel as existing for the lifetime of a particular data
>>>> stream, and not have it be associated with either producer or consumer.
>>>> Here's an example:
>>>>
>>>> https://play.golang.org/p/aEAXXtz2X1g
>>>>
>>>> The channel here is closed after all producers have exited, and all
>>>> consumers continue to run until the channel is drained of data.
>>>>
>>>> The producers are managed by something somewhere in your code - and
>>>> that is the scope at which it makes sense to create channel ownership. I've
>>>> used a waitgroup to ensure that the channel is closed after all producers
>>>> exit, but you can use whatever barrier construct you want.
>>>>
>>>> Even if you must have a channel per producer, you can safely close the
>>>> producer side, without notifying the downstream about this. The example
>>>> early in the thread uses multiple channels, with one channel being used to
>>>> signal that the producers should exit. Channels aren't really the right
>>>> model for this, you want a thread safe flag of some sort. For example:
>>>>
>>>> var exitFlag uint64
>>>> func producer(chan data int, wg *sync.WaitGroup) {
>>>> defer wg.Done()
>>>> for {
>>>> shouldExit := atomic.LoadUint64()
>>>> if shouldExit == 1 {
>>>> return
>>>> }
>>>> chan <- rand.Intn(100)
>>>> }
>>>> }
>>>>
>>>> Here's 10 producers and 3 consumers sharing a channel and closing it
>>>> safely upon receiving an exit flag:
>>>> https://play.golang.org/p/RiKi1PGVSvF
>>>>
>>>> -- Marcin
>>>>
>>>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara
>>>> wrote:
>>>>
>>>>> I do not think priority select is *necessary*, it could be a nice
>>>>> addition if the performance does not change.
>>>>>
>>>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>>>
>>>>>> Hi Robert,
>>>>>>
>>>>>> From the article: """To bound more the problem, in my case, you
>>>>>> control the writers but not the readers"""
>>>>>>
>>>>>> So what I was trying to do was to be able to close, with mutiple
>>>>>> writers, while being transparent for the readers. The readers only need
>>>>>> to
>>>>>> read as usual form the channel.
>>>>>>
>>>>>> For example, if you want to write a library where the user just reads
>>>>>> from a channel,
Re: [go-nuts] An old problem: lack of priority select cases
ealt with on the "user-side". There are many kinds of priority in
>>>>> general, and trying to implement something in the language itself would
>>>>> IMO either be too specific compared to the nessecary time to do so or it
>>>>> would probably have a huge overhead on the "classical' use case of the
>>>>> select construct.
>>>>> + the fact that it is apparently already possible using RWMutexes.
>>>>>
>>>>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz a
>>>>>> écrit :
>>>>>> Think of a channel as existing for the lifetime of a particular data
>>>>>> stream, and not have it be associated with either producer or consumer.
>>>>>> Here's an example:
>>>>>>
>>>>>> https://play.golang.org/p/aEAXXtz2X1g
>>>>>>
>>>>>> The channel here is closed after all producers have exited, and all
>>>>>> consumers continue to run until the channel is drained of data.
>>>>>>
>>>>>> The producers are managed by something somewhere in your code - and that
>>>>>> is the scope at which it makes sense to create channel ownership. I've
>>>>>> used a waitgroup to ensure that the channel is closed after all
>>>>>> producers exit, but you can use whatever barrier construct you want.
>>>>>>
>>>>>> Even if you must have a channel per producer, you can safely close the
>>>>>> producer side, without notifying the downstream about this. The example
>>>>>> early in the thread uses multiple channels, with one channel being used
>>>>>> to signal that the producers should exit. Channels aren't really the
>>>>>> right model for this, you want a thread safe flag of some sort. For
>>>>>> example:
>>>>>>
>>>>>> var exitFlag uint64
>>>>>> func producer(chan data int, wg *sync.WaitGroup) {
>>>>>> defer wg.Done()
>>>>>> for {
>>>>>> shouldExit := atomic.LoadUint64()
>>>>>> if shouldExit == 1 {
>>>>>> return
>>>>>> }
>>>>>> chan <- rand.Intn(100)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Here's 10 producers and 3 consumers sharing a channel and closing it
>>>>>> safely upon receiving an exit flag:
>>>>>> https://play.golang.org/p/RiKi1PGVSvF
>>>>>>
>>>>>> -- Marcin
>>>>>>
>>>>>>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara wrote:
>>>>>>> I do not think priority select is *necessary*, it could be a nice
>>>>>>> addition if the performance does not change.
>>>>>>>
>>>>>>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> From the article: """To bound more the problem, in my case, you
>>>>>>>> control the writers but not the readers"""
>>>>>>>>
>>>>>>>> So what I was trying to do was to be able to close, with mutiple
>>>>>>>> writers, while being transparent for the readers. The readers only
>>>>>>>> need to read as usual form the channel.
>>>>>>>>
>>>>>>>> For example, if you want to write a library where the user just reads
>>>>>>>> from a channel, this is an approach I found where the user of the
>>>>>>>> lirbary deos nto have to do anything special. Of course, there might
>>>>>>>> be another solution, but if you need to modify the reader we are
>>>>>>>> talking about a different problem.
>>>>>>>>
>>>>>>>> Cheers!!
>>>>>>>>
>>>>>>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels
>>>>>>>>> wrote:
>>>>>>>>> A better solution is to wrap the writes using a RWLock, grab the read
>>>>>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>>>>>
>>>>>>>>>
Re: [go-nuts] An old problem: lack of priority select cases
really be otherwise) for channel use alone.
>>>>>
>>>>> As for the priority using selects, I think it's more of something to be
>>>>> dealt with on the "user-side". There are many kinds of priority in
>>>>> general, and trying to implement something in the language itself would
>>>>> IMO either be too specific compared to the nessecary time to do so or it
>>>>> would probably have a huge overhead on the "classical' use case of the
>>>>> select construct.
>>>>> + the fact that it is apparently already possible using RWMutexes.
>>>>>
>>>>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz a
>>>>>> écrit :
>>>>>> Think of a channel as existing for the lifetime of a particular data
>>>>>> stream, and not have it be associated with either producer or consumer.
>>>>>> Here's an example:
>>>>>>
>>>>>> https://play.golang.org/p/aEAXXtz2X1g
>>>>>>
>>>>>> The channel here is closed after all producers have exited, and all
>>>>>> consumers continue to run until the channel is drained of data.
>>>>>>
>>>>>> The producers are managed by something somewhere in your code - and that
>>>>>> is the scope at which it makes sense to create channel ownership. I've
>>>>>> used a waitgroup to ensure that the channel is closed after all
>>>>>> producers exit, but you can use whatever barrier construct you want.
>>>>>>
>>>>>> Even if you must have a channel per producer, you can safely close the
>>>>>> producer side, without notifying the downstream about this. The example
>>>>>> early in the thread uses multiple channels, with one channel being used
>>>>>> to signal that the producers should exit. Channels aren't really the
>>>>>> right model for this, you want a thread safe flag of some sort. For
>>>>>> example:
>>>>>>
>>>>>> var exitFlag uint64
>>>>>> func producer(chan data int, wg *sync.WaitGroup) {
>>>>>> defer wg.Done()
>>>>>> for {
>>>>>> shouldExit := atomic.LoadUint64()
>>>>>> if shouldExit == 1 {
>>>>>> return
>>>>>> }
>>>>>> chan <- rand.Intn(100)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Here's 10 producers and 3 consumers sharing a channel and closing it
>>>>>> safely upon receiving an exit flag:
>>>>>> https://play.golang.org/p/RiKi1PGVSvF
>>>>>>
>>>>>> -- Marcin
>>>>>>
>>>>>>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara wrote:
>>>>>>> I do not think priority select is *necessary*, it could be a nice
>>>>>>> addition if the performance does not change.
>>>>>>>
>>>>>>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> From the article: """To bound more the problem, in my case, you
>>>>>>>> control the writers but not the readers"""
>>>>>>>>
>>>>>>>> So what I was trying to do was to be able to close, with mutiple
>>>>>>>> writers, while being transparent for the readers. The readers only
>>>>>>>> need to read as usual form the channel.
>>>>>>>>
>>>>>>>> For example, if you want to write a library where the user just reads
>>>>>>>> from a channel, this is an approach I found where the user of the
>>>>>>>> lirbary deos nto have to do anything special. Of course, there might
>>>>>>>> be another solution, but if you need to modify the reader we are
>>>>>>>> talking about a different problem.
>>>>>>>>
>>>>>>>> Cheers!!
>>>>>>>>
>>>>>>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels
>>>>>>>>> wrote:
>>>>>>>>> A better solution is to wrap the writes using a RWLock, grab th
Re: [go-nuts] An old problem: lack of priority select cases
I agree mostly with T L, and I say in the article in the section "Testing for race conditions" https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 . The race detector will detect race conditions if they happen during the execution of the tests. But, as they are race conditions, some timings and ordering will not trigger them, and hence the race detector. I run my tests with: go test -cpu=1,9,55,99 -race -count=1000 -failfast and run it several times, while running other programs in the background to create more "scheduling noise". Many times in my original code I had race conditions but it was not detected many of the runs of the tests. So I have validated this empirically. On Sunday, September 1, 2019 at 9:13:18 PM UTC+2, Robert Engels wrote: > > Not true. The race detector does not detect certain cases and can > overreport. One the memory model becomes fully specified it may not be the > case but if would be very hard to implement something that didn’t work as > I’ve said > > Still you can just as easily change the other two accesses to be atomic > but it’s not needed. > > On Sep 1, 2019, at 12:55 PM, T L > wrote: > > You can simply validate it by run: go run -race main.go > for you program: https://play.golang.org/p/JRSEPU3Uf17 > > > On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote: >> >> The memory model is pretty unspecified but they’re working on it. As a >> defacto behavior it is pretty hard to have what I stated not be the case. >> >> On Sep 1, 2019, at 9:46 AM, T L wrote: >> >> This is not true, at least no Go official documentation admits this. >> >> On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >>> >>> That is incorrect. The atomic operations must exhibit the same happens >>> before relationships as the mutex. If the mutex flushes the related cache >>> lines the atomic load will pick it up. >>> >>> On Aug 31, 2019, at 10:55 PM, T L wrote: >>> >>> >>> >>> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >>>> >>>> Yes, that is why the original code did not use a lock on the read but >>>> the read of the flag was wrong. The version I posted in the other thread >>>> works fine locally. time.Sleep() has problems in the playground >>>> >>> >>> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? >>> No no, it is not a good ideas to use mutex in write but atomic in read >>> to avoid concurrently accessing the same value. >>> >>> >>>> >>>> On Aug 31, 2019, at 7:50 AM, T L wrote: >>>> >>>> >>>> >>>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>>>> >>>>> If you comment out the read method then all threads will block. That >>>>> is the the behavior of an unbuffered channel - a writer blocks until a >>>>> reader is ready. Which is why you always need a valid reader running. >>>>> Unless the channel is closed and then the writer will panic. >>>>> >>>>> The code I provided is valid. >>>>> >>>> >>>> In fact, if I comment out the write instead read part, the code will >>>> also crash on all goroutines are blocked. >>>> >>>> >>>>> >>>>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>>>> >>>>> >>>>> >>>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>>>> >>>>>> You changed the Read() method incorrectly - it should be using the >>>>>> Read lock, not the Write lock. >>>>>> >>>>>> Still, as I pointed out when I posted it, Play has a problem where it >>>>>> aborts if all routines are sleeping (not just blocked), so you need to >>>>>> run >>>>>> it locally. >>>>>> >>>>> >>>>> My fault. But it doesn't matter, for the Read method is never called >>>>> (I commented it off). >>>>> It also crash locally for all goroutines are blocked. >>>>> >>>>> >>>>>> -Original Message- >>>>>> From: T L >>>>>> Sent: Aug 30, 2019 12:05 PM >>>>>> To: golang-nuts >>>>>> Subject: Re: [go-nuts] An old problem: lack of priority selec
Re: [go-nuts] An old problem: lack of priority select cases
and all
>>> consumers continue to run until the channel is drained of data.
>>>
>>> The producers are managed by something somewhere in your code - and that
>>> is the scope at which it makes sense to create channel ownership. I've used
>>> a waitgroup to ensure that the channel is closed after all producers exit,
>>> but you can use whatever barrier construct you want.
>>>
>>> Even if you must have a channel per producer, you can safely close the
>>> producer side, without notifying the downstream about this. The example
>>> early in the thread uses multiple channels, with one channel being used to
>>> signal that the producers should exit. Channels aren't really the right
>>> model for this, you want a thread safe flag of some sort. For example:
>>>
>>> var exitFlag uint64
>>> func producer(chan data int, wg *sync.WaitGroup) {
>>> defer wg.Done()
>>> for {
>>> shouldExit := atomic.LoadUint64()
>>> if shouldExit == 1 {
>>> return
>>> }
>>> chan <- rand.Intn(100)
>>> }
>>> }
>>>
>>> Here's 10 producers and 3 consumers sharing a channel and closing it
>>> safely upon receiving an exit flag:
>>> https://play.golang.org/p/RiKi1PGVSvF
>>>
>>> -- Marcin
>>>
>>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara wrote:
>>>
>>>> I do not think priority select is *necessary*, it could be a nice
>>>> addition if the performance does not change.
>>>>
>>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>>
>>>>> Hi Robert,
>>>>>
>>>>> From the article: """To bound more the problem, in my case, you
>>>>> control the writers but not the readers"""
>>>>>
>>>>> So what I was trying to do was to be able to close, with mutiple
>>>>> writers, while being transparent for the readers. The readers only need
>>>>> to
>>>>> read as usual form the channel.
>>>>>
>>>>> For example, if you want to write a library where the user just reads
>>>>> from a channel, this is an approach I found where the user of the lirbary
>>>>> deos nto have to do anything special. Of course, there might be another
>>>>> solution, but if you need to modify the reader we are talking about a
>>>>> different problem.
>>>>>
>>>>> Cheers!!
>>>>>
>>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>>>>
>>>>>> A better solution is to wrap the writes using a RWLock, grab the read
>>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>>
>>>>>> Just encapsulate it all in a MultiWriterChannel struct - generics
>>>>>> would help here :)
>>>>>>
>>>>>> -Original Message-
>>>>>> From: Leo Lara
>>>>>> Sent: Aug 28, 2019 11:24 AM
>>>>>> To: golang-nuts
>>>>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases
>>>>>>
>>>>>> This is connected with my article:
>>>>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>>>>>>
>>>>>> I think there I show it is possible to workaround that limitation
>>>>>> using standard Go tools. Of course, the code would be simple with
>>>>>> priority
>>>>>> select, but also perhaps select would become less efficient.
>>>>>>
>>>>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>>>>>>
>>>>>>> The old thread:
>>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>>>
>>>>>>> Go channels are flexible, but in practice, I often encountered some
>>>>>>> situations in which channel are hard to use.
>>>>>>> Given an example:
>>>>>>>
>>>>>>> import "math/rand"
>>>>>>>
>>>>>>> type Producer struct {
>>>>>>> data chan int
>>>>>>> closed chan struct{}
>>>>>>
Re: [go-nuts] An old problem: lack of priority select cases
On Sunday, September 1, 2019 at 2:05:49 PM UTC-4, Albert Tedja wrote:
>
> This is something I ran into a while back, and made a library for it,
> though, I prefer not to spam the mailing list. Feel free to send me a dm
> and I'll send you a github link if you are interested.
>
It would be great if you can share the library here. I'm surely interested.
And I think many other gophers also have interests. :)
>
> On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote:
>>
>>
>>
>> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>>>
>>>
>>>
>>> On Sat, 31 Aug 2019 at 10:02, T L wrote:
>>>
On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>
>
>
> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>
>> The reason you're wanting priority select is because you are shutting
>> down the data channel preemptively, but you can wait for an
>> acknowledgement
>> from the run goroutine instead:
>>
>> https://play.golang.org/p/qSWluYy4ifl
>>
>>
> Your solution is clever. The Close method can be called multiple time
> safely.
> Is there such a beautiful solution for multiple senders?
>
>
Translating a multi-senders problem to a single sender problem is the
only way I can get:
https://play.golang.org/p/dAppUxP96g4
>>>
>>> The answer really depends on what you're actually trying to do. What are
>>> the multiple senders? What's the actual problem you're trying to solve?
>>>
>>> I'd fairly sure you'll be able do what you want without requiring a
>>> prioritised select, which is what this thread was about.
>>>
>>> cheers,
>>> rog.
>>>
>>>
>> Yes, there are ways to handle the problem of uncertain number of senders,
>> but there are no simple ways.
>> A mechanism must be designed to avoid any sender writing to a closed
>> channel.
>>
>>
>>>
>
>> On Wed, 28 Aug 2019 at 18:06, T L wrote:
>>
>>> The old thread:
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p := {
>>> data: make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>>
>>> go p.run()
>>>
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance
>>> order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a
>>> higher priority than the second one,
>>> then coding will be much happier for the use cases like the above
>>> one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a
>>> channel.
>>> * for senders, data will never be sent to closed channel.
>>>
>>> But, as Go 1 doesn't support priority select cases, it is much
>>> tedious to implement the code
>>> satisfying the above listed requirements. The final implementation
>>> is often very ugly and inefficient.
>>>
>>> Does anyone else also experience the pain?
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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 golan...@googlegroups.com.
To view this discussion on the web visit
Re: [go-nuts] An old problem: lack of priority select cases
Not true. The race detector does not detect certain cases and can overreport. One the memory model becomes fully specified it may not be the case but if would be very hard to implement something that didn’t work as I’ve said Still you can just as easily change the other two accesses to be atomic but it’s not needed. > On Sep 1, 2019, at 12:55 PM, T L wrote: > > You can simply validate it by run: go run -race main.go > for you program: https://play.golang.org/p/JRSEPU3Uf17 > > >> On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote: >> The memory model is pretty unspecified but they’re working on it. As a >> defacto behavior it is pretty hard to have what I stated not be the case. >> >>> On Sep 1, 2019, at 9:46 AM, T L wrote: >>> >>> This is not true, at least no Go official documentation admits this. >>> >>>> On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >>>> That is incorrect. The atomic operations must exhibit the same happens >>>> before relationships as the mutex. If the mutex flushes the related cache >>>> lines the atomic load will pick it up. >>>> >>>>> On Aug 31, 2019, at 10:55 PM, T L wrote: >>>>> >>>>> >>>>> >>>>>> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >>>>>> Yes, that is why the original code did not use a lock on the read but >>>>>> the read of the flag was wrong. The version I posted in the other thread >>>>>> works fine locally. time.Sleep() has problems in the playground >>>>> >>>>> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? >>>>> No no, it is not a good ideas to use mutex in write but atomic in read to >>>>> avoid concurrently accessing the same value. >>>>> >>>>>> >>>>>>> On Aug 31, 2019, at 7:50 AM, T L wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>>>>>>> If you comment out the read method then all threads will block. That >>>>>>>> is the the behavior of an unbuffered channel - a writer blocks until a >>>>>>>> reader is ready. Which is why you always need a valid reader running. >>>>>>>> Unless the channel is closed and then the writer will panic. >>>>>>>> >>>>>>>> The code I provided is valid. >>>>>>> >>>>>>> In fact, if I comment out the write instead read part, the code will >>>>>>> also crash on all goroutines are blocked. >>>>>>> >>>>>>>> >>>>>>>>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>>>>>>>> You changed the Read() method incorrectly - it should be using the >>>>>>>>>> Read lock, not the Write lock. >>>>>>>>>> >>>>>>>>>> Still, as I pointed out when I posted it, Play has a problem where >>>>>>>>>> it aborts if all routines are sleeping (not just blocked), so you >>>>>>>>>> need to run it locally. >>>>>>>>> >>>>>>>>> My fault. But it doesn't matter, for the Read method is never called >>>>>>>>> (I commented it off). >>>>>>>>> It also crash locally for all goroutines are blocked. >>>>>>>>> >>>>>>>>>> -Original Message- >>>>>>>>>> From: T L >>>>>>>>>> Sent: Aug 30, 2019 12:05 PM >>>>>>>>>> To: golang-nuts >>>>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>
Re: [go-nuts] An old problem: lack of priority select cases
This is something I ran into a while back, and made a library for it,
though, I prefer not to spam the mailing list. Feel free to send me a dm
and I'll send you a github link if you are interested.
On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote:
>
>
>
> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>>
>>
>>
>> On Sat, 31 Aug 2019 at 10:02, T L wrote:
>>
>>>
>>>
>>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>
> The reason you're wanting priority select is because you are shutting
> down the data channel preemptively, but you can wait for an
> acknowledgement
> from the run goroutine instead:
>
> https://play.golang.org/p/qSWluYy4ifl
>
>
Your solution is clever. The Close method can be called multiple time
safely.
Is there such a beautiful solution for multiple senders?
>>>
>>> Translating a multi-senders problem to a single sender problem is the
>>> only way I can get:
>>> https://play.golang.org/p/dAppUxP96g4
>>>
>>
>> The answer really depends on what you're actually trying to do. What are
>> the multiple senders? What's the actual problem you're trying to solve?
>>
>> I'd fairly sure you'll be able do what you want without requiring a
>> prioritised select, which is what this thread was about.
>>
>> cheers,
>> rog.
>>
>>
> Yes, there are ways to handle the problem of uncertain number of senders,
> but there are no simple ways.
> A mechanism must be designed to avoid any sender writing to a closed
> channel.
>
>
>>
>>>
> On Wed, 28 Aug 2019 at 18:06, T L wrote:
>
>> The old thread:
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := {
>> data: make(chan int),
>> closed: make(chan struct{}),
>> }
>>
>> go p.run()
>>
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance
>> order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a
>> higher priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a
>> channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much
>> tedious to implement the code
>> satisfying the above listed requirements. The final implementation is
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>> --
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com
>>>
>>>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
Re: [go-nuts] An old problem: lack of priority select cases
You can simply validate it by run: go run -race main.go for you program: https://play.golang.org/p/JRSEPU3Uf17 On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote: > > The memory model is pretty unspecified but they’re working on it. As a > defacto behavior it is pretty hard to have what I stated not be the case. > > On Sep 1, 2019, at 9:46 AM, T L > wrote: > > This is not true, at least no Go official documentation admits this. > > On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >> >> That is incorrect. The atomic operations must exhibit the same happens >> before relationships as the mutex. If the mutex flushes the related cache >> lines the atomic load will pick it up. >> >> On Aug 31, 2019, at 10:55 PM, T L wrote: >> >> >> >> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >>> >>> Yes, that is why the original code did not use a lock on the read but >>> the read of the flag was wrong. The version I posted in the other thread >>> works fine locally. time.Sleep() has problems in the playground >>> >> >> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? >> No no, it is not a good ideas to use mutex in write but atomic in read to >> avoid concurrently accessing the same value. >> >> >>> >>> On Aug 31, 2019, at 7:50 AM, T L wrote: >>> >>> >>> >>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>>> >>>> If you comment out the read method then all threads will block. That is >>>> the the behavior of an unbuffered channel - a writer blocks until a reader >>>> is ready. Which is why you always need a valid reader running. Unless the >>>> channel is closed and then the writer will panic. >>>> >>>> The code I provided is valid. >>>> >>> >>> In fact, if I comment out the write instead read part, the code will >>> also crash on all goroutines are blocked. >>> >>> >>>> >>>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>>> >>>> >>>> >>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>>> >>>>> You changed the Read() method incorrectly - it should be using the >>>>> Read lock, not the Write lock. >>>>> >>>>> Still, as I pointed out when I posted it, Play has a problem where it >>>>> aborts if all routines are sleeping (not just blocked), so you need to >>>>> run >>>>> it locally. >>>>> >>>> >>>> My fault. But it doesn't matter, for the Read method is never called (I >>>> commented it off). >>>> It also crash locally for all goroutines are blocked. >>>> >>>> >>>>> -Original Message- >>>>> From: T L >>>>> Sent: Aug 30, 2019 12:05 PM >>>>> To: golang-nuts >>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>> >>>>> >>>>> >>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>>>> >>>>>> >>>>>> Makes no difference in the code I posted as long as they all use >>>>>> the same MultiWriterChannel. In fact, others can be late started, as >>>>>> they >>>>>> will fail fast if the channel is already closed. >>>>>> >>>>> >>>>> https://play.golang.org/p/pcwIu2w8ZRb >>>>> >>>>> All go routines are blocked in the modified version. >>>>> >>>>> >>>>>> -Original Message- >>>>>> From: T L >>>>>> Sent: Aug 30, 2019 11:13 AM >>>>>> To: golang-nuts >>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>> >>>>>> >>>>>> >>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>>>>> >>>>>>> I don't think so. Why do you think that is the case? The RWLock is >>>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it >>>>>>> is >>>>>>> guaranteed to get it (as the code is structured) - the subsequ
Re: [go-nuts] An old problem: lack of priority select cases
The memory model is pretty unspecified but they’re working on it. As a defacto behavior it is pretty hard to have what I stated not be the case. > On Sep 1, 2019, at 9:46 AM, T L wrote: > > This is not true, at least no Go official documentation admits this. > >> On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >> That is incorrect. The atomic operations must exhibit the same happens >> before relationships as the mutex. If the mutex flushes the related cache >> lines the atomic load will pick it up. >> >>> On Aug 31, 2019, at 10:55 PM, T L wrote: >>> >>> >>> >>>> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >>>> Yes, that is why the original code did not use a lock on the read but the >>>> read of the flag was wrong. The version I posted in the other thread works >>>> fine locally. time.Sleep() has problems in the playground >>> >>> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? >>> No no, it is not a good ideas to use mutex in write but atomic in read to >>> avoid concurrently accessing the same value. >>> >>>> >>>>> On Aug 31, 2019, at 7:50 AM, T L wrote: >>>>> >>>>> >>>>> >>>>>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>>>>> If you comment out the read method then all threads will block. That is >>>>>> the the behavior of an unbuffered channel - a writer blocks until a >>>>>> reader is ready. Which is why you always need a valid reader running. >>>>>> Unless the channel is closed and then the writer will panic. >>>>>> >>>>>> The code I provided is valid. >>>>> >>>>> In fact, if I comment out the write instead read part, the code will also >>>>> crash on all goroutines are blocked. >>>>> >>>>>> >>>>>>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>>>>>> You changed the Read() method incorrectly - it should be using the >>>>>>>> Read lock, not the Write lock. >>>>>>>> >>>>>>>> Still, as I pointed out when I posted it, Play has a problem where it >>>>>>>> aborts if all routines are sleeping (not just blocked), so you need to >>>>>>>> run it locally. >>>>>>> >>>>>>> My fault. But it doesn't matter, for the Read method is never called (I >>>>>>> commented it off). >>>>>>> It also crash locally for all goroutines are blocked. >>>>>>> >>>>>>>> -Original Message- >>>>>>>> From: T L >>>>>>>> Sent: Aug 30, 2019 12:05 PM >>>>>>>> To: golang-nuts >>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>>>>>>> >>>>>>>>> Makes no difference in the code I posted as long as they all use >>>>>>>>> the same MultiWriterChannel. In fact, others can be late started, as >>>>>>>>> they will fail fast if the channel is already closed. >>>>>>>> >>>>>>>> https://play.golang.org/p/pcwIu2w8ZRb >>>>>>>> >>>>>>>> All go routines are blocked in the modified version. >>>>>>>> >>>>>>>>> -Original Message- >>>>>>>>> From: T L >>>>>>>>> Sent: Aug 30, 2019 11:13 AM >>>>>>>>> To: golang-nuts >>>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>>>>>>>> I don't think so. Why do you think that is
Re: [go-nuts] An old problem: lack of priority select cases
This is not true, at least no Go official documentation admits this. On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: > > That is incorrect. The atomic operations must exhibit the same happens > before relationships as the mutex. If the mutex flushes the related cache > lines the atomic load will pick it up. > > On Aug 31, 2019, at 10:55 PM, T L > wrote: > > > > On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >> >> Yes, that is why the original code did not use a lock on the read but the >> read of the flag was wrong. The version I posted in the other thread works >> fine locally. time.Sleep() has problems in the playground >> > > You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? > No no, it is not a good ideas to use mutex in write but atomic in read to > avoid concurrently accessing the same value. > > >> >> On Aug 31, 2019, at 7:50 AM, T L wrote: >> >> >> >> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>> >>> If you comment out the read method then all threads will block. That is >>> the the behavior of an unbuffered channel - a writer blocks until a reader >>> is ready. Which is why you always need a valid reader running. Unless the >>> channel is closed and then the writer will panic. >>> >>> The code I provided is valid. >>> >> >> In fact, if I comment out the write instead read part, the code will also >> crash on all goroutines are blocked. >> >> >>> >>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>> >>> >>> >>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>> >>>> You changed the Read() method incorrectly - it should be using the Read >>>> lock, not the Write lock. >>>> >>>> Still, as I pointed out when I posted it, Play has a problem where it >>>> aborts if all routines are sleeping (not just blocked), so you need to run >>>> it locally. >>>> >>> >>> My fault. But it doesn't matter, for the Read method is never called (I >>> commented it off). >>> It also crash locally for all goroutines are blocked. >>> >>> >>>> -Original Message- >>>> From: T L >>>> Sent: Aug 30, 2019 12:05 PM >>>> To: golang-nuts >>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>> >>>> >>>> >>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>>> >>>>> >>>>> Makes no difference in the code I posted as long as they all use >>>>> the same MultiWriterChannel. In fact, others can be late started, as they >>>>> will fail fast if the channel is already closed. >>>>> >>>> >>>> https://play.golang.org/p/pcwIu2w8ZRb >>>> >>>> All go routines are blocked in the modified version. >>>> >>>> >>>>> -Original Message- >>>>> From: T L >>>>> Sent: Aug 30, 2019 11:13 AM >>>>> To: golang-nuts >>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>> >>>>> >>>>> >>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>>>> >>>>>> I don't think so. Why do you think that is the case? The RWLock is >>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it >>>>>> is >>>>>> guaranteed to get it (as the code is structured) - the subsequent >>>>>> readers >>>>>> will queue behind the "writer = closer". >>>>>> >>>>> >>>>> How about unknown/random number of senders and readers? >>>>> >>>>> >>>>>> >>>>>> -Original Message- >>>>>> From: T L >>>>>> Sent: Aug 30, 2019 8:50 AM >>>>>> To: golang-nuts >>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>> >>>>>> @Robert >>>>>> I think there is a difference between the code of @Leo and you. >>>>>> In you code, the Wirte/Read/Close are all possible to block for ever. >>
Re: [go-nuts] An old problem: lack of priority select cases
That is incorrect. The atomic operations must exhibit the same happens before relationships as the mutex. If the mutex flushes the related cache lines the atomic load will pick it up. > On Aug 31, 2019, at 10:55 PM, T L wrote: > > > >> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >> Yes, that is why the original code did not use a lock on the read but the >> read of the flag was wrong. The version I posted in the other thread works >> fine locally. time.Sleep() has problems in the playground > > You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? > No no, it is not a good ideas to use mutex in write but atomic in read to > avoid concurrently accessing the same value. > >> >>> On Aug 31, 2019, at 7:50 AM, T L wrote: >>> >>> >>> >>>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >>>> If you comment out the read method then all threads will block. That is >>>> the the behavior of an unbuffered channel - a writer blocks until a reader >>>> is ready. Which is why you always need a valid reader running. Unless the >>>> channel is closed and then the writer will panic. >>>> >>>> The code I provided is valid. >>> >>> In fact, if I comment out the write instead read part, the code will also >>> crash on all goroutines are blocked. >>> >>>> >>>>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>>>> >>>>> >>>>> >>>>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>>>> You changed the Read() method incorrectly - it should be using the Read >>>>>> lock, not the Write lock. >>>>>> >>>>>> Still, as I pointed out when I posted it, Play has a problem where it >>>>>> aborts if all routines are sleeping (not just blocked), so you need to >>>>>> run it locally. >>>>> >>>>> My fault. But it doesn't matter, for the Read method is never called (I >>>>> commented it off). >>>>> It also crash locally for all goroutines are blocked. >>>>> >>>>>> -Original Message- >>>>>> From: T L >>>>>> Sent: Aug 30, 2019 12:05 PM >>>>>> To: golang-nuts >>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>> >>>>>> >>>>>> >>>>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>>>>> >>>>>>> Makes no difference in the code I posted as long as they all use >>>>>>> the same MultiWriterChannel. In fact, others can be late started, as >>>>>>> they will fail fast if the channel is already closed. >>>>>> >>>>>> https://play.golang.org/p/pcwIu2w8ZRb >>>>>> >>>>>> All go routines are blocked in the modified version. >>>>>> >>>>>>> -----Original Message- >>>>>>> From: T L >>>>>>> Sent: Aug 30, 2019 11:13 AM >>>>>>> To: golang-nuts >>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>>>>>> I don't think so. Why do you think that is the case? The RWLock is >>>>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, >>>>>>>> it is guaranteed to get it (as the code is structured) - the >>>>>>>> subsequent readers will queue behind the "writer = closer". >>>>>>> >>>>>>> How about unknown/random number of senders and readers? >>>>>>> >>>>>>>> >>>>>>>> -Original Message- >>>>>>>> From: T L >>>>>>>> Sent: Aug 30, 2019 8:50 AM >>>>>>>> To: golang-nuts >>>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>>> >>>>>>>> @Robert >>>>>>>> I think there is a difference between the code
Re: [go-nuts] An old problem: lack of priority select cases
On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>
>
>
> On Sat, 31 Aug 2019 at 10:02, T L > wrote:
>
>>
>>
>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>>>
>>>
>>>
>>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
The reason you're wanting priority select is because you are shutting
down the data channel preemptively, but you can wait for an
acknowledgement
from the run goroutine instead:
https://play.golang.org/p/qSWluYy4ifl
>>> Your solution is clever. The Close method can be called multiple time
>>> safely.
>>> Is there such a beautiful solution for multiple senders?
>>>
>>>
>>
>> Translating a multi-senders problem to a single sender problem is the
>> only way I can get:
>> https://play.golang.org/p/dAppUxP96g4
>>
>
> The answer really depends on what you're actually trying to do. What are
> the multiple senders? What's the actual problem you're trying to solve?
>
> I'd fairly sure you'll be able do what you want without requiring a
> prioritised select, which is what this thread was about.
>
> cheers,
> rog.
>
>
Yes, there are ways to handle the problem of uncertain number of senders,
but there are no simple ways.
A mechanism must be designed to avoid any sender writing to a closed
channel.
>
>>
>>>
On Wed, 28 Aug 2019 at 18:06, T L wrote:
> The old thread:
> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>
> Go channels are flexible, but in practice, I often encountered some
> situations in which channel are hard to use.
> Given an example:
>
> import "math/rand"
>
> type Producer struct {
> data chan int
> closed chan struct{}
> }
>
> func NewProducer() *Producer {
> p := {
> data: make(chan int),
> closed: make(chan struct{}),
> }
>
> go p.run()
>
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> // If non-blocking cases are selected by their appearance
> order,
> // then the following slect block is a perfect use.
> select {
> case(0) <-p.closed: return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Produce) Clsoe() {
> close(p.closed)
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
> If the first case in the select block in the above example has a
> higher priority than the second one,
> then coding will be much happier for the use cases like the above one.
>
> In short, the above use case requires:
> * for receivers, data streaming end is notified by the close of a
> channel.
> * for senders, data will never be sent to closed channel.
>
> But, as Go 1 doesn't support priority select cases, it is much tedious
> to implement the code
> satisfying the above listed requirements. The final implementation is
> often very ugly and inefficient.
>
> Does anyone else also experience the pain?
>
> --
> 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 golan...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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 golan...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/432f9d63-5223-4119-b7e7-b1eb2dd57cdc%40googlegroups.com.
Re: [go-nuts] An old problem: lack of priority select cases
On Sat, 31 Aug 2019 at 10:02, T L wrote:
>
>
> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>>
>>
>>
>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>>
>>> The reason you're wanting priority select is because you are shutting
>>> down the data channel preemptively, but you can wait for an acknowledgement
>>> from the run goroutine instead:
>>>
>>> https://play.golang.org/p/qSWluYy4ifl
>>>
>>>
>> Your solution is clever. The Close method can be called multiple time
>> safely.
>> Is there such a beautiful solution for multiple senders?
>>
>>
>
> Translating a multi-senders problem to a single sender problem is the only
> way I can get:
> https://play.golang.org/p/dAppUxP96g4
>
The answer really depends on what you're actually trying to do. What are
the multiple senders? What's the actual problem you're trying to solve?
I'd fairly sure you'll be able do what you want without requiring a
prioritised select, which is what this thread was about.
cheers,
rog.
>
>>
>>> On Wed, 28 Aug 2019 at 18:06, T L wrote:
>>>
The old thread:
https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
Go channels are flexible, but in practice, I often encountered some
situations in which channel are hard to use.
Given an example:
import "math/rand"
type Producer struct {
data chan int
closed chan struct{}
}
func NewProducer() *Producer {
p := {
data: make(chan int),
closed: make(chan struct{}),
}
go p.run()
return p
}
func (p *Produce) Stream() chan int {
return p.data
}
func (p *Producer) run() {
for {
// If non-blocking cases are selected by their appearance order,
// then the following slect block is a perfect use.
select {
case(0) <-p.closed: return
case p.data <- rand.Int():
}
}
}
func (p *Produce) Clsoe() {
close(p.closed)
close(p.data)
}
func main() {
p := NewProducer()
for n := p.Stream() {
// use n ...
}
}
If the first case in the select block in the above example has a higher
priority than the second one,
then coding will be much happier for the use cases like the above one.
In short, the above use case requires:
* for receivers, data streaming end is notified by the close of a
channel.
* for senders, data will never be sent to closed channel.
But, as Go 1 doesn't support priority select cases, it is much tedious
to implement the code
satisfying the above listed requirements. The final implementation is
often very ugly and inefficient.
Does anyone else also experience the pain?
--
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 golan...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJhgaciEMCBkbDV7Fp3Mk5gnRyvsG2TB5JZve%3Di6tvwq%2BZs1uw%40mail.gmail.com.
Re: [go-nuts] An old problem: lack of priority select cases
On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: > > Yes, that is why the original code did not use a lock on the read but the > read of the flag was wrong. The version I posted in the other thread works > fine locally. time.Sleep() has problems in the playground > You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? No no, it is not a good ideas to use mutex in write but atomic in read to avoid concurrently accessing the same value. > > On Aug 31, 2019, at 7:50 AM, T L > wrote: > > > > On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >> >> If you comment out the read method then all threads will block. That is >> the the behavior of an unbuffered channel - a writer blocks until a reader >> is ready. Which is why you always need a valid reader running. Unless the >> channel is closed and then the writer will panic. >> >> The code I provided is valid. >> > > In fact, if I comment out the write instead read part, the code will also > crash on all goroutines are blocked. > > >> >> On Aug 31, 2019, at 2:40 AM, T L wrote: >> >> >> >> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>> >>> You changed the Read() method incorrectly - it should be using the Read >>> lock, not the Write lock. >>> >>> Still, as I pointed out when I posted it, Play has a problem where it >>> aborts if all routines are sleeping (not just blocked), so you need to run >>> it locally. >>> >> >> My fault. But it doesn't matter, for the Read method is never called (I >> commented it off). >> It also crash locally for all goroutines are blocked. >> >> >>> -Original Message- >>> From: T L >>> Sent: Aug 30, 2019 12:05 PM >>> To: golang-nuts >>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>> >>> >>> >>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>> >>>> >>>> Makes no difference in the code I posted as long as they all use >>>> the same MultiWriterChannel. In fact, others can be late started, as they >>>> will fail fast if the channel is already closed. >>>> >>> >>> https://play.golang.org/p/pcwIu2w8ZRb >>> >>> All go routines are blocked in the modified version. >>> >>> >>>> -Original Message- >>>> From: T L >>>> Sent: Aug 30, 2019 11:13 AM >>>> To: golang-nuts >>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>> >>>> >>>> >>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>>> >>>>> I don't think so. Why do you think that is the case? The RWLock is >>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it >>>>> is >>>>> guaranteed to get it (as the code is structured) - the subsequent readers >>>>> will queue behind the "writer = closer". >>>>> >>>> >>>> How about unknown/random number of senders and readers? >>>> >>>> >>>>> >>>>> -Original Message- >>>>> From: T L >>>>> Sent: Aug 30, 2019 8:50 AM >>>>> To: golang-nuts >>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>> >>>>> @Robert >>>>> I think there is a difference between the code of @Leo and you. >>>>> In you code, the Wirte/Read/Close are all possible to block for ever. >>>>> >>>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >>>>>> >>>>>> >>>>>> Oops. You are right. The original used two different methods Closed() >>>>>> and Read() and when I refactored I forgot to add the Read lock to the >>>>>> Read(). That's why you always have code reviews... >>>>>> >>>>>> -Original Message- >>>>>> From: T L >>>>>> Sent: Aug 29, 2019 6:25 PM >>>>>> To: golang-nuts >>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>> >>>>>> >>>>>> >>>>>> On Wednesday, August 28, 2019
Re: [go-nuts] An old problem: lack of priority select cases
Yes, that is why the original code did not use a lock on the read but the read of the flag was wrong. The version I posted in the other thread works fine locally. time.Sleep() has problems in the playground > On Aug 31, 2019, at 7:50 AM, T L wrote: > > > >> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >> If you comment out the read method then all threads will block. That is the >> the behavior of an unbuffered channel - a writer blocks until a reader is >> ready. Which is why you always need a valid reader running. Unless the >> channel is closed and then the writer will panic. >> >> The code I provided is valid. > > In fact, if I comment out the write instead read part, the code will also > crash on all goroutines are blocked. > >> >>> On Aug 31, 2019, at 2:40 AM, T L wrote: >>> >>> >>> >>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >>>> You changed the Read() method incorrectly - it should be using the Read >>>> lock, not the Write lock. >>>> >>>> Still, as I pointed out when I posted it, Play has a problem where it >>>> aborts if all routines are sleeping (not just blocked), so you need to run >>>> it locally. >>> >>> My fault. But it doesn't matter, for the Read method is never called (I >>> commented it off). >>> It also crash locally for all goroutines are blocked. >>> >>>> -Original Message- >>>> From: T L >>>> Sent: Aug 30, 2019 12:05 PM >>>> To: golang-nuts >>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>> >>>> >>>> >>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>>> >>>>> Makes no difference in the code I posted as long as they all use the >>>>> same MultiWriterChannel. In fact, others can be late started, as they >>>>> will fail fast if the channel is already closed. >>>> >>>> https://play.golang.org/p/pcwIu2w8ZRb >>>> >>>> All go routines are blocked in the modified version. >>>> >>>>> -Original Message- >>>>> From: T L >>>>> Sent: Aug 30, 2019 11:13 AM >>>>> To: golang-nuts >>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>> >>>>> >>>>> >>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>>>> I don't think so. Why do you think that is the case? The RWLock is >>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it >>>>>> is guaranteed to get it (as the code is structured) - the subsequent >>>>>> readers will queue behind the "writer = closer". >>>>> >>>>> How about unknown/random number of senders and readers? >>>>> >>>>>> >>>>>> -Original Message----- >>>>>> From: T L >>>>>> Sent: Aug 30, 2019 8:50 AM >>>>>> To: golang-nuts >>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>> >>>>>> @Robert >>>>>> I think there is a difference between the code of @Leo and you. >>>>>> In you code, the Wirte/Read/Close are all possible to block for ever. >>>>>> >>>>>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >>>>>>> >>>>>>> Oops. You are right. The original used two different methods Closed() >>>>>>> and Read() and when I refactored I forgot to add the Read lock to the >>>>>>> Read(). That's why you always have code reviews... >>>>>>> -Original Message- >>>>>>> From: T L >>>>>>> Sent: Aug 29, 2019 6:25 PM >>>>>>> To: golang-nuts >>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels >>>>>>>> wrote: >>>>>>>> Here is a version using RWLock https://play.golang.org/p
Re: [go-nuts] An old problem: lack of priority select cases
On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: > > If you comment out the read method then all threads will block. That is > the the behavior of an unbuffered channel - a writer blocks until a reader > is ready. Which is why you always need a valid reader running. Unless the > channel is closed and then the writer will panic. > > The code I provided is valid. > In fact, if I comment out the write instead read part, the code will also crash on all goroutines are blocked. > > On Aug 31, 2019, at 2:40 AM, T L > wrote: > > > > On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >> >> You changed the Read() method incorrectly - it should be using the Read >> lock, not the Write lock. >> >> Still, as I pointed out when I posted it, Play has a problem where it >> aborts if all routines are sleeping (not just blocked), so you need to run >> it locally. >> > > My fault. But it doesn't matter, for the Read method is never called (I > commented it off). > It also crash locally for all goroutines are blocked. > > >> -Original Message----- >> From: T L >> Sent: Aug 30, 2019 12:05 PM >> To: golang-nuts >> Subject: Re: [go-nuts] An old problem: lack of priority select cases >> >> >> >> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>> >>> >>> Makes no difference in the code I posted as long as they all use the >>> same MultiWriterChannel. In fact, others can be late started, as they will >>> fail fast if the channel is already closed. >>> >> >> https://play.golang.org/p/pcwIu2w8ZRb >> >> All go routines are blocked in the modified version. >> >> >>> -Original Message- >>> From: T L >>> Sent: Aug 30, 2019 11:13 AM >>> To: golang-nuts >>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>> >>> >>> >>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>> >>>> I don't think so. Why do you think that is the case? The RWLock is >>>> "fair" in the sense that once the 'closer' attempts to get the lock, it is >>>> guaranteed to get it (as the code is structured) - the subsequent readers >>>> will queue behind the "writer = closer". >>>> >>> >>> How about unknown/random number of senders and readers? >>> >>> >>>> >>>> -Original Message- >>>> From: T L >>>> Sent: Aug 30, 2019 8:50 AM >>>> To: golang-nuts >>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>> >>>> @Robert >>>> I think there is a difference between the code of @Leo and you. >>>> In you code, the Wirte/Read/Close are all possible to block for ever. >>>> >>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >>>>> >>>>> >>>>> Oops. You are right. The original used two different methods Closed() >>>>> and Read() and when I refactored I forgot to add the Read lock to the >>>>> Read(). That's why you always have code reviews... >>>>> >>>>> -Original Message- >>>>> From: T L >>>>> Sent: Aug 29, 2019 6:25 PM >>>>> To: golang-nuts >>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>> >>>>> >>>>> >>>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels >>>>> wrote: >>>>>> >>>>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf >>>>>> >>>>> >>>>> Doesn't the Read method need to be guarded by the reader lock? >>>>> >>>>> >>>>> >>>>>> >>>>>> It won’t run correctly in the playground because it terminates when >>>>>> all routines are asleep - which happens during the test (not sure why it >>>>>> does this, as sleeping is different than a deadlock). >>>>>> >>>>>> It is probably less efficient, and less orderly than the other >>>>>> example using WaitGroup but you get the idea I hope. It forcibly >>>>>> terminates >>>>>> the writers before they compl
Re: [go-nuts] An old problem: lack of priority select cases
If you comment out the read method then all threads will block. That is the the behavior of an unbuffered channel - a writer blocks until a reader is ready. Which is why you always need a valid reader running. Unless the channel is closed and then the writer will panic. The code I provided is valid. > On Aug 31, 2019, at 2:40 AM, T L wrote: > > > >> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >> You changed the Read() method incorrectly - it should be using the Read >> lock, not the Write lock. >> >> Still, as I pointed out when I posted it, Play has a problem where it aborts >> if all routines are sleeping (not just blocked), so you need to run it >> locally. > > My fault. But it doesn't matter, for the Read method is never called (I > commented it off). > It also crash locally for all goroutines are blocked. > >> -Original Message- >> From: T L >> Sent: Aug 30, 2019 12:05 PM >> To: golang-nuts >> Subject: Re: [go-nuts] An old problem: lack of priority select cases >> >> >> >>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>> >>> Makes no difference in the code I posted as long as they all use the >>> same MultiWriterChannel. In fact, others can be late started, as they will >>> fail fast if the channel is already closed. >> >> https://play.golang.org/p/pcwIu2w8ZRb >> >> All go routines are blocked in the modified version. >> >>> -Original Message- >>> From: T L >>> Sent: Aug 30, 2019 11:13 AM >>> To: golang-nuts >>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>> >>> >>> >>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>>> I don't think so. Why do you think that is the case? The RWLock is "fair" >>>> in the sense that once the 'closer' attempts to get the lock, it is >>>> guaranteed to get it (as the code is structured) - the subsequent readers >>>> will queue behind the "writer = closer". >>> >>> How about unknown/random number of senders and readers? >>> >>>> >>>> -Original Message- >>>> From: T L >>>> Sent: Aug 30, 2019 8:50 AM >>>> To: golang-nuts >>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>> >>>> @Robert >>>> I think there is a difference between the code of @Leo and you. >>>> In you code, the Wirte/Read/Close are all possible to block for ever. >>>> >>>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >>>>> >>>>> Oops. You are right. The original used two different methods Closed() and >>>>> Read() and when I refactored I forgot to add the Read lock to the Read(). >>>>> That's why you always have code reviews... >>>>> -Original Message- >>>>> From: T L >>>>> Sent: Aug 29, 2019 6:25 PM >>>>> To: golang-nuts >>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>>> >>>>> >>>>> >>>>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote: >>>>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf >>>>> >>>>> Doesn't the Read method need to be guarded by the reader lock? >>>>> >>>>> >>>>>> >>>>>> It won’t run correctly in the playground because it terminates when all >>>>>> routines are asleep - which happens during the test (not sure why it >>>>>> does this, as sleeping is different than a deadlock). >>>>>> >>>>>> It is probably less efficient, and less orderly than the other example >>>>>> using WaitGroup but you get the idea I hope. It forcibly terminates the >>>>>> writers before they complete by design. >>>>>> >>>>>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux >>>>>>> wrote: >>>>>>> >>>>>>> One should also be careful regarding the conceptual demands he or she >>>>>>> is making. >>>>>>> Having a shared resource (that is complex enough that it cannot be >>>>>>> atomically accessed
Re: [go-nuts] An old problem: lack of priority select cases
On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>
>
>
> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>
>> The reason you're wanting priority select is because you are shutting
>> down the data channel preemptively, but you can wait for an acknowledgement
>> from the run goroutine instead:
>>
>> https://play.golang.org/p/qSWluYy4ifl
>>
>>
> Your solution is clever. The Close method can be called multiple time
> safely.
> Is there such a beautiful solution for multiple senders?
>
>
Translating a multi-senders problem to a single sender problem is the only
way I can get:
https://play.golang.org/p/dAppUxP96g4
>
>> On Wed, 28 Aug 2019 at 18:06, T L wrote:
>>
>>> The old thread:
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p := {
>>> data: make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>>
>>> go p.run()
>>>
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a higher
>>> priority than the second one,
>>> then coding will be much happier for the use cases like the above one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a
>>> channel.
>>> * for senders, data will never be sent to closed channel.
>>>
>>> But, as Go 1 doesn't support priority select cases, it is much tedious
>>> to implement the code
>>> satisfying the above listed requirements. The final implementation is
>>> often very ugly and inefficient.
>>>
>>> Does anyone else also experience the pain?
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com.
Re: [go-nuts] An old problem: lack of priority select cases
On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>
> The reason you're wanting priority select is because you are shutting down
> the data channel preemptively, but you can wait for an acknowledgement from
> the run goroutine instead:
>
> https://play.golang.org/p/qSWluYy4ifl
>
>
Your solution is clever. The Close method can be called multiple time
safely.
Is there such a beautiful solution for multiple senders?
>
> On Wed, 28 Aug 2019 at 18:06, T L > wrote:
>
>> The old thread:
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := {
>> data: make(chan int),
>> closed: make(chan struct{}),
>> }
>>
>> go p.run()
>>
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to
>> implement the code
>> satisfying the above listed requirements. The final implementation is
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>> --
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/15b4b573-ee9c-4552-be78-84b303173ad7%40googlegroups.com.
Re: [go-nuts] An old problem: lack of priority select cases
On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: > > You changed the Read() method incorrectly - it should be using the Read > lock, not the Write lock. > > Still, as I pointed out when I posted it, Play has a problem where it > aborts if all routines are sleeping (not just blocked), so you need to run > it locally. > My fault. But it doesn't matter, for the Read method is never called (I commented it off). It also crash locally for all goroutines are blocked. > -Original Message- > From: T L > Sent: Aug 30, 2019 12:05 PM > To: golang-nuts > Subject: Re: [go-nuts] An old problem: lack of priority select cases > > > > On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >> >> >> Makes no difference in the code I posted as long as they all use the >> same MultiWriterChannel. In fact, others can be late started, as they will >> fail fast if the channel is already closed. >> > > https://play.golang.org/p/pcwIu2w8ZRb > > All go routines are blocked in the modified version. > > >> -----Original Message----- >> From: T L >> Sent: Aug 30, 2019 11:13 AM >> To: golang-nuts >> Subject: Re: [go-nuts] An old problem: lack of priority select cases >> >> >> >> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >>> >>> I don't think so. Why do you think that is the case? The RWLock is >>> "fair" in the sense that once the 'closer' attempts to get the lock, it is >>> guaranteed to get it (as the code is structured) - the subsequent readers >>> will queue behind the "writer = closer". >>> >> >> How about unknown/random number of senders and readers? >> >> >>> >>> -Original Message- >>> From: T L >>> Sent: Aug 30, 2019 8:50 AM >>> To: golang-nuts >>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>> >>> @Robert >>> I think there is a difference between the code of @Leo and you. >>> In you code, the Wirte/Read/Close are all possible to block for ever. >>> >>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >>>> >>>> >>>> Oops. You are right. The original used two different methods Closed() >>>> and Read() and when I refactored I forgot to add the Read lock to the >>>> Read(). That's why you always have code reviews... >>>> >>>> -Original Message- >>>> From: T L >>>> Sent: Aug 29, 2019 6:25 PM >>>> To: golang-nuts >>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>>> >>>> >>>> >>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote: >>>>> >>>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf >>>>> >>>> >>>> Doesn't the Read method need to be guarded by the reader lock? >>>> >>>> >>>> >>>>> >>>>> It won’t run correctly in the playground because it terminates when >>>>> all routines are asleep - which happens during the test (not sure why it >>>>> does this, as sleeping is different than a deadlock). >>>>> >>>>> It is probably less efficient, and less orderly than the other example >>>>> using WaitGroup but you get the idea I hope. It forcibly terminates the >>>>> writers before they complete by design. >>>>> >>>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux >>>>> wrote: >>>>> >>>>> One should also be careful regarding the conceptual demands he or she >>>>> is making. >>>>> Having a shared resource (that is complex enough that it cannot be >>>>> atomically accessed or modified) means essentially that "having multiple >>>>> writers being transparent to the readers", fundamentally, is not possible. >>>>> >>>>> From the moment itself when such a resource is shared, there must be >>>>> some sort of mecanism (that one using resources atomically usable) that >>>>> ensures the integrity of it. >>>>> Maybe what you're talking about is having it transparent in terms of >>>>> code, in which case we both agree, but if you're looking for something >>>>> transparent in essence, as
Re: [go-nuts] An old problem: lack of priority select cases
The reason you're wanting priority select is because you are shutting down
the data channel preemptively, but you can wait for an acknowledgement from
the run goroutine instead:
https://play.golang.org/p/qSWluYy4ifl
On Wed, 28 Aug 2019 at 18:06, T L wrote:
> The old thread:
> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>
> Go channels are flexible, but in practice, I often encountered some
> situations in which channel are hard to use.
> Given an example:
>
> import "math/rand"
>
> type Producer struct {
> data chan int
> closed chan struct{}
> }
>
> func NewProducer() *Producer {
> p := {
> data: make(chan int),
> closed: make(chan struct{}),
> }
>
> go p.run()
>
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> // If non-blocking cases are selected by their appearance order,
> // then the following slect block is a perfect use.
> select {
> case(0) <-p.closed: return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Produce) Clsoe() {
> close(p.closed)
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
> If the first case in the select block in the above example has a higher
> priority than the second one,
> then coding will be much happier for the use cases like the above one.
>
> In short, the above use case requires:
> * for receivers, data streaming end is notified by the close of a channel.
> * for senders, data will never be sent to closed channel.
>
> But, as Go 1 doesn't support priority select cases, it is much tedious to
> implement the code
> satisfying the above listed requirements. The final implementation is
> often very ugly and inefficient.
>
> Does anyone else also experience the pain?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJhgacgdNrNCsEN_-oAPAbzLwq6fhakuvPjg3%3Dyg-VLTe1hkqQ%40mail.gmail.com.
Re: [go-nuts] An old problem: lack of priority select cases
You changed the Read() method incorrectly - it should be using the Read lock, not the Write lock.Still, as I pointed out when I posted it, Play has a problem where it aborts if all routines are sleeping (not just blocked), so you need to run it locally.-Original Message- From: T L Sent: Aug 30, 2019 12:05 PM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:Makes no difference in the code I posted as long as they all use the same MultiWriterChannel. In fact, others can be late started, as they will fail fast if the channel is already closed.https://play.golang.org/p/pcwIu2w8ZRbAll go routines are blocked in the modified version. -Original Message- From: T L Sent: Aug 30, 2019 11:13 AM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:I don't think so. Why do you think that is the case? The RWLock is "fair" in the sense that once the 'closer' attempts to get the lock, it is guaranteed to get it (as the code is structured) - the subsequent readers will queue behind the "writer = closer".How about unknown/random number of senders and readers? -Original Message- From: T L Sent: Aug 30, 2019 8:50 AM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases @Robert I think there is a difference between the code of @Leo and you.In you code, the Wirte/Read/Close are all possible to block for ever.On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:Oops. You are right. The original used two different methods Closed() and Read() and when I refactored I forgot to add the Read lock to the Read(). That's why you always have code reviews...-Original Message- From: T L Sent: Aug 29, 2019 6:25 PM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlfDoesn't the Read method need to be guarded by the reader lock? It won’t run correctly in the playground because it terminates when all routines are asleep - which happens during the test (not sure why it does this, as sleeping is different than a deadlock).It is probably less efficient, and less orderly than the other example using WaitGroup but you get the idea I hope. It forcibly terminates the writers before they complete by design.On Aug 28, 2019, at 4:09 PM, Michel Levieux <m.le...@capitaldata.fr> wrote:One should also be careful regarding the conceptual demands he or she is making.Having a shared resource (that is complex enough that it cannot be atomically accessed or modified) means essentially that "having multiple writers being transparent to the readers", fundamentally, is not possible.From the moment itself when such a resource is shared, there must be some sort of mecanism (that one using resources atomically usable) that ensures the integrity of it.Maybe what you're talking about is having it transparent in terms of code, in which case we both agree, but if you're looking for something transparent in essence, as in performance, logical construction and all the rest, I think there is a misunderstanding here: even if it was added in the language, there would be many many things going on under the hood, as it is already (and cannot really be otherwise) for channel use alone.As for the priority using selects, I think it's more of something to be dealt with on the "user-side". There are many kinds of priority in general, and trying to implement something in the language itself would IMO either be too specific compared to the nessecary time to do so or it would probably have a huge overhead on the "classical' use case of the select construct.+ the fact that it is apparently already possible using RWMutexes.Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz <mar...@gmail.com> a écrit :Think of a channel as existing for the lifetime of a particular data stream, and not have it be associated with either producer or consumer. Here's an example:https://play.golang.org/p/aEAXXtz2X1gThe channel here is closed after all producers have exited, and all consumers continue to run until the channel is drained of data.The producers are managed by something somewhere in your code - and that is the scope at which it makes sense to create channel ownership. I've used a waitgroup to ensure that the channel is closed after all producers exit, but you can use whatever barrier construct you want.Even if you must have a channel per producer, you can safely close the producer side, without notifying the downstream about this. The example early in the thread uses multiple channels, with one channel being used to signal that the producers should exit. Channels aren't rea
Re: [go-nuts] An old problem: lack of priority select cases
On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: > > > Makes no difference in the code I posted as long as they all use the > same MultiWriterChannel. In fact, others can be late started, as they will > fail fast if the channel is already closed. > https://play.golang.org/p/pcwIu2w8ZRb All go routines are blocked in the modified version. > -Original Message- > From: T L > Sent: Aug 30, 2019 11:13 AM > To: golang-nuts > Subject: Re: [go-nuts] An old problem: lack of priority select cases > > > > On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: >> >> I don't think so. Why do you think that is the case? The RWLock is "fair" >> in the sense that once the 'closer' attempts to get the lock, it is >> guaranteed to get it (as the code is structured) - the subsequent readers >> will queue behind the "writer = closer". >> > > How about unknown/random number of senders and readers? > > >> >> -Original Message- >> From: T L >> Sent: Aug 30, 2019 8:50 AM >> To: golang-nuts >> Subject: Re: [go-nuts] An old problem: lack of priority select cases >> >> @Robert >> I think there is a difference between the code of @Leo and you. >> In you code, the Wirte/Read/Close are all possible to block for ever. >> >> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >>> >>> >>> Oops. You are right. The original used two different methods Closed() >>> and Read() and when I refactored I forgot to add the Read lock to the >>> Read(). That's why you always have code reviews... >>> >>> -Original Message- >>> From: T L >>> Sent: Aug 29, 2019 6:25 PM >>> To: golang-nuts >>> Subject: Re: [go-nuts] An old problem: lack of priority select cases >>> >>> >>> >>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote: >>>> >>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf >>>> >>> >>> Doesn't the Read method need to be guarded by the reader lock? >>> >>> >>> >>>> >>>> It won’t run correctly in the playground because it terminates when all >>>> routines are asleep - which happens during the test (not sure why it does >>>> this, as sleeping is different than a deadlock). >>>> >>>> It is probably less efficient, and less orderly than the other example >>>> using WaitGroup but you get the idea I hope. It forcibly terminates the >>>> writers before they complete by design. >>>> >>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux >>>> wrote: >>>> >>>> One should also be careful regarding the conceptual demands he or she >>>> is making. >>>> Having a shared resource (that is complex enough that it cannot be >>>> atomically accessed or modified) means essentially that "having multiple >>>> writers being transparent to the readers", fundamentally, is not possible. >>>> >>>> From the moment itself when such a resource is shared, there must be >>>> some sort of mecanism (that one using resources atomically usable) that >>>> ensures the integrity of it. >>>> Maybe what you're talking about is having it transparent in terms of >>>> code, in which case we both agree, but if you're looking for something >>>> transparent in essence, as in performance, logical construction and all >>>> the >>>> rest, I think there is a misunderstanding here: even if it was added in >>>> the >>>> language, there would be many many things going on under the hood, as it >>>> is >>>> already (and cannot really be otherwise) for channel use alone. >>>> >>>> As for the priority using selects, I think it's more of something to be >>>> dealt with on the "user-side". There are many kinds of priority in >>>> general, >>>> and trying to implement something in the language itself would IMO either >>>> be too specific compared to the nessecary time to do so or it would >>>> probably have a huge overhead on the "classical' use case of the select >>>> construct. >>>> + the fact that it is apparently already possible using RWMutexes. >>>> >>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz a >>&
Re: [go-nuts] An old problem: lack of priority select cases
Makes no difference in the code I posted as long as they all use the same MultiWriterChannel. In fact, others can be late started, as they will fail fast if the channel is already closed.-Original Message-
From: T L
Sent: Aug 30, 2019 11:13 AM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:I don't think so. Why do you think that is the case? The RWLock is "fair" in the sense that once the 'closer' attempts to get the lock, it is guaranteed to get it (as the code is structured) - the subsequent readers will queue behind the "writer = closer".How about unknown/random number of senders and readers? -Original Message-
From: T L
Sent: Aug 30, 2019 8:50 AM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
@Robert I think there is a difference between the code of @Leo and you.In you code, the Wirte/Read/Close are all possible to block for ever.On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:Oops. You are right. The original used two different methods Closed() and Read() and when I refactored I forgot to add the Read lock to the Read(). That's why you always have code reviews...-Original Message-
From: T L
Sent: Aug 29, 2019 6:25 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlfDoesn't the Read method need to be guarded by the reader lock? It won’t run correctly in the playground because it terminates when all routines are asleep - which happens during the test (not sure why it does this, as sleeping is different than a deadlock).It is probably less efficient, and less orderly than the other example using WaitGroup but you get the idea I hope. It forcibly terminates the writers before they complete by design.On Aug 28, 2019, at 4:09 PM, Michel Levieux <m.le...@capitaldata.fr> wrote:One should also be careful regarding the conceptual demands he or she is making.Having a shared resource (that is complex enough that it cannot be atomically accessed or modified) means essentially that "having multiple writers being transparent to the readers", fundamentally, is not possible.From the moment itself when such a resource is shared, there must be some sort of mecanism (that one using resources atomically usable) that ensures the integrity of it.Maybe what you're talking about is having it transparent in terms of code, in which case we both agree, but if you're looking for something transparent in essence, as in performance, logical construction and all the rest, I think there is a misunderstanding here: even if it was added in the language, there would be many many things going on under the hood, as it is already (and cannot really be otherwise) for channel use alone.As for the priority using selects, I think it's more of something to be dealt with on the "user-side". There are many kinds of priority in general, and trying to implement something in the language itself would IMO either be too specific compared to the nessecary time to do so or it would probably have a huge overhead on the "classical' use case of the select construct.+ the fact that it is apparently already possible using RWMutexes.Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz <mar...@gmail.com> a écrit :Think of a channel as existing for the lifetime of a particular data stream, and not have it be associated with either producer or consumer. Here's an example:https://play.golang.org/p/aEAXXtz2X1gThe channel here is closed after all producers have exited, and all consumers continue to run until the channel is drained of data.The producers are managed by something somewhere in your code - and that is the scope at which it makes sense to create channel ownership. I've used a waitgroup to ensure that the channel is closed after all producers exit, but you can use whatever barrier construct you want.Even if you must have a channel per producer, you can safely close the producer side, without notifying the downstream about this. The example early in the thread uses multiple channels, with one channel being used to signal that the producers should exit. Channels aren't really the right model for this, you want a thread safe flag of some sort. For example:var exitFlag uint64func producer(chan data int, wg *sync.WaitGroup) { defer wg.Done() for { shouldExit := atomic.LoadUint64() if shouldExit == 1 { return } chan <- rand.Intn(100) }}Here's 10 producers and 3 consumers sharing a channel and closing it safely upon receiving an exit flag:https://play.golang.org/p/RiKi1PGVSvF-- MarcinOn Wed, Aug 28, 2019 at 11:29 AM Leo Lara <l...@leopoldolara.com> wrote:I do not
Re: [go-nuts] An old problem: lack of priority select cases
On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote: > > I don't think so. Why do you think that is the case? The RWLock is "fair" > in the sense that once the 'closer' attempts to get the lock, it is > guaranteed to get it (as the code is structured) - the subsequent readers > will queue behind the "writer = closer". > How about unknown/random number of senders and readers? > > -Original Message- > From: T L > Sent: Aug 30, 2019 8:50 AM > To: golang-nuts > Subject: Re: [go-nuts] An old problem: lack of priority select cases > > @Robert > I think there is a difference between the code of @Leo and you. > In you code, the Wirte/Read/Close are all possible to block for ever. > > On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote: >> >> >> Oops. You are right. The original used two different methods Closed() and >> Read() and when I refactored I forgot to add the Read lock to the Read(). >> That's why you always have code reviews... >> >> -Original Message----- >> From: T L >> Sent: Aug 29, 2019 6:25 PM >> To: golang-nuts >> Subject: Re: [go-nuts] An old problem: lack of priority select cases >> >> >> >> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote: >>> >>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf >>> >> >> Doesn't the Read method need to be guarded by the reader lock? >> >> >> >>> >>> It won’t run correctly in the playground because it terminates when all >>> routines are asleep - which happens during the test (not sure why it does >>> this, as sleeping is different than a deadlock). >>> >>> It is probably less efficient, and less orderly than the other example >>> using WaitGroup but you get the idea I hope. It forcibly terminates the >>> writers before they complete by design. >>> >>> On Aug 28, 2019, at 4:09 PM, Michel Levieux >>> wrote: >>> >>> One should also be careful regarding the conceptual demands he or she is >>> making. >>> Having a shared resource (that is complex enough that it cannot be >>> atomically accessed or modified) means essentially that "having multiple >>> writers being transparent to the readers", fundamentally, is not possible. >>> >>> From the moment itself when such a resource is shared, there must be >>> some sort of mecanism (that one using resources atomically usable) that >>> ensures the integrity of it. >>> Maybe what you're talking about is having it transparent in terms of >>> code, in which case we both agree, but if you're looking for something >>> transparent in essence, as in performance, logical construction and all the >>> rest, I think there is a misunderstanding here: even if it was added in the >>> language, there would be many many things going on under the hood, as it is >>> already (and cannot really be otherwise) for channel use alone. >>> >>> As for the priority using selects, I think it's more of something to be >>> dealt with on the "user-side". There are many kinds of priority in general, >>> and trying to implement something in the language itself would IMO either >>> be too specific compared to the nessecary time to do so or it would >>> probably have a huge overhead on the "classical' use case of the select >>> construct. >>> + the fact that it is apparently already possible using RWMutexes. >>> >>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz a >>> écrit : >>> >>>> Think of a channel as existing for the lifetime of a particular data >>>> stream, and not have it be associated with either producer or consumer. >>>> Here's an example: >>>> >>>> https://play.golang.org/p/aEAXXtz2X1g >>>> >>>> The channel here is closed after all producers have exited, and all >>>> consumers continue to run until the channel is drained of data. >>>> >>>> The producers are managed by something somewhere in your code - and >>>> that is the scope at which it makes sense to create channel ownership. >>>> I've >>>> used a waitgroup to ensure that the channel is closed after all producers >>>> exit, but you can use whatever barrier construct you want. >>>> >>>> Even if you must have a channel per producer, you can safely close the >>
Re: [go-nuts] An old problem: lack of priority select cases
I don't think so. Why do you think that is the case? The RWLock is "fair" in the sense that once the 'closer' attempts to get the lock, it is guaranteed to get it (as the code is structured) - the subsequent readers will queue behind the "writer = closer".-Original Message-
From: T L
Sent: Aug 30, 2019 8:50 AM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
@Robert I think there is a difference between the code of @Leo and you.In you code, the Wirte/Read/Close are all possible to block for ever.On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:Oops. You are right. The original used two different methods Closed() and Read() and when I refactored I forgot to add the Read lock to the Read(). That's why you always have code reviews...-Original Message-
From: T L
Sent: Aug 29, 2019 6:25 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlfDoesn't the Read method need to be guarded by the reader lock? It won’t run correctly in the playground because it terminates when all routines are asleep - which happens during the test (not sure why it does this, as sleeping is different than a deadlock).It is probably less efficient, and less orderly than the other example using WaitGroup but you get the idea I hope. It forcibly terminates the writers before they complete by design.On Aug 28, 2019, at 4:09 PM, Michel Levieux <m.le...@capitaldata.fr> wrote:One should also be careful regarding the conceptual demands he or she is making.Having a shared resource (that is complex enough that it cannot be atomically accessed or modified) means essentially that "having multiple writers being transparent to the readers", fundamentally, is not possible.From the moment itself when such a resource is shared, there must be some sort of mecanism (that one using resources atomically usable) that ensures the integrity of it.Maybe what you're talking about is having it transparent in terms of code, in which case we both agree, but if you're looking for something transparent in essence, as in performance, logical construction and all the rest, I think there is a misunderstanding here: even if it was added in the language, there would be many many things going on under the hood, as it is already (and cannot really be otherwise) for channel use alone.As for the priority using selects, I think it's more of something to be dealt with on the "user-side". There are many kinds of priority in general, and trying to implement something in the language itself would IMO either be too specific compared to the nessecary time to do so or it would probably have a huge overhead on the "classical' use case of the select construct.+ the fact that it is apparently already possible using RWMutexes.Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz <mar...@gmail.com> a écrit :Think of a channel as existing for the lifetime of a particular data stream, and not have it be associated with either producer or consumer. Here's an example:https://play.golang.org/p/aEAXXtz2X1gThe channel here is closed after all producers have exited, and all consumers continue to run until the channel is drained of data.The producers are managed by something somewhere in your code - and that is the scope at which it makes sense to create channel ownership. I've used a waitgroup to ensure that the channel is closed after all producers exit, but you can use whatever barrier construct you want.Even if you must have a channel per producer, you can safely close the producer side, without notifying the downstream about this. The example early in the thread uses multiple channels, with one channel being used to signal that the producers should exit. Channels aren't really the right model for this, you want a thread safe flag of some sort. For example:var exitFlag uint64func producer(chan data int, wg *sync.WaitGroup) { defer wg.Done() for { shouldExit := atomic.LoadUint64() if shouldExit == 1 { return } chan <- rand.Intn(100) }}Here's 10 producers and 3 consumers sharing a channel and closing it safely upon receiving an exit flag:https://play.golang.org/p/RiKi1PGVSvF-- MarcinOn Wed, Aug 28, 2019 at 11:29 AM Leo Lara <l...@leopoldolara.com> wrote:I do not think priority select is *necessary*, it could be a nice addition if the performance does not change.On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:Hi Robert,From the article: """To bound more the problem, in my case, you control the writers but not the readers"""So what I was trying to do was to be able to close, with mutiple writers, while being transparent for the readers. The readers only need to read as usual form
Re: [go-nuts] An old problem: lack of priority select cases
@Robert
I think there is a difference between the code of @Leo and you.
In you code, the Wirte/Read/Close are all possible to block for ever.
On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>
>
> Oops. You are right. The original used two different methods Closed() and
> Read() and when I refactored I forgot to add the Read lock to the Read().
> That's why you always have code reviews...
>
> -Original Message-
> From: T L
> Sent: Aug 29, 2019 6:25 PM
> To: golang-nuts
> Subject: Re: [go-nuts] An old problem: lack of priority select cases
>
>
>
> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>>
>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>
>
> Doesn't the Read method need to be guarded by the reader lock?
>
>
>
>>
>> It won’t run correctly in the playground because it terminates when all
>> routines are asleep - which happens during the test (not sure why it does
>> this, as sleeping is different than a deadlock).
>>
>> It is probably less efficient, and less orderly than the other example
>> using WaitGroup but you get the idea I hope. It forcibly terminates the
>> writers before they complete by design.
>>
>> On Aug 28, 2019, at 4:09 PM, Michel Levieux
>> wrote:
>>
>> One should also be careful regarding the conceptual demands he or she is
>> making.
>> Having a shared resource (that is complex enough that it cannot be
>> atomically accessed or modified) means essentially that "having multiple
>> writers being transparent to the readers", fundamentally, is not possible.
>>
>> From the moment itself when such a resource is shared, there must be some
>> sort of mecanism (that one using resources atomically usable) that ensures
>> the integrity of it.
>> Maybe what you're talking about is having it transparent in terms of
>> code, in which case we both agree, but if you're looking for something
>> transparent in essence, as in performance, logical construction and all the
>> rest, I think there is a misunderstanding here: even if it was added in the
>> language, there would be many many things going on under the hood, as it is
>> already (and cannot really be otherwise) for channel use alone.
>>
>> As for the priority using selects, I think it's more of something to be
>> dealt with on the "user-side". There are many kinds of priority in general,
>> and trying to implement something in the language itself would IMO either
>> be too specific compared to the nessecary time to do so or it would
>> probably have a huge overhead on the "classical' use case of the select
>> construct.
>> + the fact that it is apparently already possible using RWMutexes.
>>
>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz a
>> écrit :
>>
>>> Think of a channel as existing for the lifetime of a particular data
>>> stream, and not have it be associated with either producer or consumer.
>>> Here's an example:
>>>
>>> https://play.golang.org/p/aEAXXtz2X1g
>>>
>>> The channel here is closed after all producers have exited, and all
>>> consumers continue to run until the channel is drained of data.
>>>
>>> The producers are managed by something somewhere in your code - and that
>>> is the scope at which it makes sense to create channel ownership. I've used
>>> a waitgroup to ensure that the channel is closed after all producers exit,
>>> but you can use whatever barrier construct you want.
>>>
>>> Even if you must have a channel per producer, you can safely close the
>>> producer side, without notifying the downstream about this. The example
>>> early in the thread uses multiple channels, with one channel being used to
>>> signal that the producers should exit. Channels aren't really the right
>>> model for this, you want a thread safe flag of some sort. For example:
>>>
>>> var exitFlag uint64
>>> func producer(chan data int, wg *sync.WaitGroup) {
>>> defer wg.Done()
>>> for {
>>> shouldExit := atomic.LoadUint64()
>>> if shouldExit == 1 {
>>> return
>>> }
>>> chan <- rand.Intn(100)
>>> }
>>> }
>>>
>>> Here's 10 producers and 3 consumers sharing a channel and closing it
>>> safely upon receiving an exit flag:
>>> https://play.golang.org/p/RiKi1PGVSvF
>>>
>>> -- Marcin
>>>
>
Re: [go-nuts] An old problem: lack of priority select cases
Oops. You are right. The original used two different methods Closed() and Read() and when I refactored I forgot to add the Read lock to the Read(). That's why you always have code reviews...-Original Message-
From: T L
Sent: Aug 29, 2019 6:25 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlfDoesn't the Read method need to be guarded by the reader lock? It won’t run correctly in the playground because it terminates when all routines are asleep - which happens during the test (not sure why it does this, as sleeping is different than a deadlock).It is probably less efficient, and less orderly than the other example using WaitGroup but you get the idea I hope. It forcibly terminates the writers before they complete by design.On Aug 28, 2019, at 4:09 PM, Michel Levieux <m.le...@capitaldata.fr> wrote:One should also be careful regarding the conceptual demands he or she is making.Having a shared resource (that is complex enough that it cannot be atomically accessed or modified) means essentially that "having multiple writers being transparent to the readers", fundamentally, is not possible.From the moment itself when such a resource is shared, there must be some sort of mecanism (that one using resources atomically usable) that ensures the integrity of it.Maybe what you're talking about is having it transparent in terms of code, in which case we both agree, but if you're looking for something transparent in essence, as in performance, logical construction and all the rest, I think there is a misunderstanding here: even if it was added in the language, there would be many many things going on under the hood, as it is already (and cannot really be otherwise) for channel use alone.As for the priority using selects, I think it's more of something to be dealt with on the "user-side". There are many kinds of priority in general, and trying to implement something in the language itself would IMO either be too specific compared to the nessecary time to do so or it would probably have a huge overhead on the "classical' use case of the select construct.+ the fact that it is apparently already possible using RWMutexes.Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz <mar...@gmail.com> a écrit :Think of a channel as existing for the lifetime of a particular data stream, and not have it be associated with either producer or consumer. Here's an example:https://play.golang.org/p/aEAXXtz2X1gThe channel here is closed after all producers have exited, and all consumers continue to run until the channel is drained of data.The producers are managed by something somewhere in your code - and that is the scope at which it makes sense to create channel ownership. I've used a waitgroup to ensure that the channel is closed after all producers exit, but you can use whatever barrier construct you want.Even if you must have a channel per producer, you can safely close the producer side, without notifying the downstream about this. The example early in the thread uses multiple channels, with one channel being used to signal that the producers should exit. Channels aren't really the right model for this, you want a thread safe flag of some sort. For example:var exitFlag uint64func producer(chan data int, wg *sync.WaitGroup) { defer wg.Done() for { shouldExit := atomic.LoadUint64() if shouldExit == 1 { return } chan <- rand.Intn(100) }}Here's 10 producers and 3 consumers sharing a channel and closing it safely upon receiving an exit flag:https://play.golang.org/p/RiKi1PGVSvF-- MarcinOn Wed, Aug 28, 2019 at 11:29 AM Leo Lara <l...@leopoldolara.com> wrote:I do not think priority select is *necessary*, it could be a nice addition if the performance does not change.On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:Hi Robert,From the article: """To bound more the problem, in my case, you control the writers but not the readers"""So what I was trying to do was to be able to close, with mutiple writers, while being transparent for the readers. The readers only need to read as usual form the channel.For example, if you want to write a library where the user just reads from a channel, this is an approach I found where the user of the lirbary deos nto have to do anything special. Of course, there might be another solution, but if you need to modify the reader we are talking about a different problem.Cheers!!On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:A better solution is to wrap the writes using a RWLock, grab the read lock for writing, and the Write lock for closing. Pretty simple.Just encapsulate it all in a MultiWriterChannel struct - generics would help here :)-Original Message-----
From:
Re: [go-nuts] An old problem: lack of priority select cases
>>> deos nto have to do anything special. Of course, there might be another
>>>> solution, but if you need to modify the reader we are talking about a
>>>> different problem.
>>>>
>>>> Cheers!!
>>>>
>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>>>
>>>>> A better solution is to wrap the writes using a RWLock, grab the read
>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>
>>>>> Just encapsulate it all in a MultiWriterChannel struct - generics
>>>>> would help here :)
>>>>>
>>>>> -Original Message-
>>>>> From: Leo Lara
>>>>> Sent: Aug 28, 2019 11:24 AM
>>>>> To: golang-nuts
>>>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases
>>>>>
>>>>> This is connected with my article:
>>>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>>>>>
>>>>> I think there I show it is possible to workaround that limitation
>>>>> using standard Go tools. Of course, the code would be simple with
>>>>> priority
>>>>> select, but also perhaps select would become less efficient.
>>>>>
>>>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>>>>>
>>>>>> The old thread:
>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>>
>>>>>> Go channels are flexible, but in practice, I often encountered some
>>>>>> situations in which channel are hard to use.
>>>>>> Given an example:
>>>>>>
>>>>>> import "math/rand"
>>>>>>
>>>>>> type Producer struct {
>>>>>> data chan int
>>>>>> closed chan struct{}
>>>>>> }
>>>>>>
>>>>>> func NewProducer() *Producer {
>>>>>> p := {
>>>>>> data: make(chan int),
>>>>>> closed: make(chan struct{}),
>>>>>> }
>>>>>>
>>>>>> go p.run()
>>>>>>
>>>>>> return p
>>>>>> }
>>>>>>
>>>>>> func (p *Produce) Stream() chan int {
>>>>>> return p.data
>>>>>> }
>>>>>>
>>>>>> func (p *Producer) run() {
>>>>>> for {
>>>>>> // If non-blocking cases are selected by their appearance
>>>>>> order,
>>>>>> // then the following slect block is a perfect use.
>>>>>> select {
>>>>>> case(0) <-p.closed: return
>>>>>> case p.data <- rand.Int():
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> func (p *Produce) Clsoe() {
>>>>>> close(p.closed)
>>>>>> close(p.data)
>>>>>> }
>>>>>>
>>>>>> func main() {
>>>>>> p := NewProducer()
>>>>>> for n := p.Stream() {
>>>>>> // use n ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> If the first case in the select block in the above example has a
>>>>>> higher priority than the second one,
>>>>>> then coding will be much happier for the use cases like the above one.
>>>>>>
>>>>>> In short, the above use case requires:
>>>>>> * for receivers, data streaming end is notified by the close of a
>>>>>> channel.
>>>>>> * for senders, data will never be sent to closed channel.
>>>>>>
>>>>>> But, as Go 1 doesn't support priority select cases, it is much
>>>>>> tedious to implement the code
>>>>>> satisfying the above listed requirements. The final implementation is
>>>>>> often very ugly and inefficient.
>>>>>>
>>>>>> Does anyone else also experience the pain?
>>>>>>
>>>>>
>>>>> --
>>>>> You received thi
Re: [go-nuts] An old problem: lack of priority select cases
ou must have a channel per producer, you can safely close the
>>>> producer side, without notifying the downstream about this. The example
>>>> early in the thread uses multiple channels, with one channel being used to
>>>> signal that the producers should exit. Channels aren't really the right
>>>> model for this, you want a thread safe flag of some sort. For example:
>>>>
>>>> var exitFlag uint64
>>>> func producer(chan data int, wg *sync.WaitGroup) {
>>>> defer wg.Done()
>>>> for {
>>>> shouldExit := atomic.LoadUint64()
>>>> if shouldExit == 1 {
>>>> return
>>>> }
>>>> chan <- rand.Intn(100)
>>>> }
>>>> }
>>>>
>>>> Here's 10 producers and 3 consumers sharing a channel and closing it
>>>> safely upon receiving an exit flag:
>>>> https://play.golang.org/p/RiKi1PGVSvF
>>>>
>>>> -- Marcin
>>>>
>>>>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara wrote:
>>>>> I do not think priority select is *necessary*, it could be a nice
>>>>> addition if the performance does not change.
>>>>>
>>>>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>>> Hi Robert,
>>>>>>
>>>>>> From the article: """To bound more the problem, in my case, you control
>>>>>> the writers but not the readers"""
>>>>>>
>>>>>> So what I was trying to do was to be able to close, with mutiple
>>>>>> writers, while being transparent for the readers. The readers only need
>>>>>> to read as usual form the channel.
>>>>>>
>>>>>> For example, if you want to write a library where the user just reads
>>>>>> from a channel, this is an approach I found where the user of the
>>>>>> lirbary deos nto have to do anything special. Of course, there might be
>>>>>> another solution, but if you need to modify the reader we are talking
>>>>>> about a different problem.
>>>>>>
>>>>>> Cheers!!
>>>>>>
>>>>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>>>>> A better solution is to wrap the writes using a RWLock, grab the read
>>>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>>>
>>>>>>> Just encapsulate it all in a MultiWriterChannel struct - generics would
>>>>>>> help here :)
>>>>>>>
>>>>>>> -Original Message-
>>>>>>> From: Leo Lara
>>>>>>> Sent: Aug 28, 2019 11:24 AM
>>>>>>> To: golang-nuts
>>>>>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases
>>>>>>>
>>>>>>> This is connected with my article:
>>>>>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>>>>>>>
>>>>>>> I think there I show it is possible to workaround that limitation using
>>>>>>> standard Go tools. Of course, the code would be simple with priority
>>>>>>> select, but also perhaps select would become less efficient.
>>>>>>>
>>>>>>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>>>>>>> The old thread:
>>>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>>>>
>>>>>>>> Go channels are flexible, but in practice, I often encountered some
>>>>>>>> situations in which channel are hard to use.
>>>>>>>> Given an example:
>>>>>>>>
>>>>>>>> import "math/rand"
>>>>>>>>
>>>>>>>> type Producer struct {
>>>>>>>> data chan int
>>>>>>>> closed chan struct{}
>>>>>>>> }
>>>>>>>>
>>>>>>>> func NewProducer() *Producer {
>>>>>>>> p := {
>>>>>>>> data: make(chan int),
>>>>>>>>
Re: [go-nuts] An old problem: lack of priority select cases
ag:
>> https://play.golang.org/p/RiKi1PGVSvF
>>
>> -- Marcin
>>
>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara > > wrote:
>>
>>> I do not think priority select is *necessary*, it could be a nice
>>> addition if the performance does not change.
>>>
>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>> From the article: """To bound more the problem, in my case, you control
>>>> the writers but not the readers"""
>>>>
>>>> So what I was trying to do was to be able to close, with mutiple
>>>> writers, while being transparent for the readers. The readers only need to
>>>> read as usual form the channel.
>>>>
>>>> For example, if you want to write a library where the user just reads
>>>> from a channel, this is an approach I found where the user of the lirbary
>>>> deos nto have to do anything special. Of course, there might be another
>>>> solution, but if you need to modify the reader we are talking about a
>>>> different problem.
>>>>
>>>> Cheers!!
>>>>
>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>>>
>>>>> A better solution is to wrap the writes using a RWLock, grab the read
>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>
>>>>> Just encapsulate it all in a MultiWriterChannel struct - generics
>>>>> would help here :)
>>>>>
>>>>> -Original Message-
>>>>> From: Leo Lara
>>>>> Sent: Aug 28, 2019 11:24 AM
>>>>> To: golang-nuts
>>>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases
>>>>>
>>>>> This is connected with my article:
>>>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>>>>>
>>>>> I think there I show it is possible to workaround that limitation
>>>>> using standard Go tools. Of course, the code would be simple with
>>>>> priority
>>>>> select, but also perhaps select would become less efficient.
>>>>>
>>>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>>>>>
>>>>>> The old thread:
>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>>
>>>>>> Go channels are flexible, but in practice, I often encountered some
>>>>>> situations in which channel are hard to use.
>>>>>> Given an example:
>>>>>>
>>>>>> import "math/rand"
>>>>>>
>>>>>> type Producer struct {
>>>>>> data chan int
>>>>>> closed chan struct{}
>>>>>> }
>>>>>>
>>>>>> func NewProducer() *Producer {
>>>>>> p := {
>>>>>> data: make(chan int),
>>>>>> closed: make(chan struct{}),
>>>>>> }
>>>>>>
>>>>>> go p.run()
>>>>>>
>>>>>> return p
>>>>>> }
>>>>>>
>>>>>> func (p *Produce) Stream() chan int {
>>>>>> return p.data
>>>>>> }
>>>>>>
>>>>>> func (p *Producer) run() {
>>>>>> for {
>>>>>> // If non-blocking cases are selected by their appearance
>>>>>> order,
>>>>>> // then the following slect block is a perfect use.
>>>>>> select {
>>>>>> case(0) <-p.closed: return
>>>>>> case p.data <- rand.Int():
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> func (p *Produce) Clsoe() {
>>>>>> close(p.closed)
>>>>>> close(p.data)
>>>>>> }
>>>>>>
>>>>>> func main() {
>>>>>> p := NewProducer()
>>>>>> for n := p.Stream() {
>>>>>> // use n ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
&g
Re: [go-nuts] An old problem: lack of priority select cases
Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
<https://play.golang.org/p/YOwuYFiqtlf>
It won’t run correctly in the playground because it terminates when all
routines are asleep - which happens during the test (not sure why it does this,
as sleeping is different than a deadlock).
It is probably less efficient, and less orderly than the other example using
WaitGroup but you get the idea I hope. It forcibly terminates the writers
before they complete by design.
> On Aug 28, 2019, at 4:09 PM, Michel Levieux wrote:
>
> One should also be careful regarding the conceptual demands he or she is
> making.
> Having a shared resource (that is complex enough that it cannot be atomically
> accessed or modified) means essentially that "having multiple writers being
> transparent to the readers", fundamentally, is not possible.
>
> From the moment itself when such a resource is shared, there must be some
> sort of mecanism (that one using resources atomically usable) that ensures
> the integrity of it.
> Maybe what you're talking about is having it transparent in terms of code, in
> which case we both agree, but if you're looking for something transparent in
> essence, as in performance, logical construction and all the rest, I think
> there is a misunderstanding here: even if it was added in the language, there
> would be many many things going on under the hood, as it is already (and
> cannot really be otherwise) for channel use alone.
>
> As for the priority using selects, I think it's more of something to be dealt
> with on the "user-side". There are many kinds of priority in general, and
> trying to implement something in the language itself would IMO either be too
> specific compared to the nessecary time to do so or it would probably have a
> huge overhead on the "classical' use case of the select construct.
> + the fact that it is apparently already possible using RWMutexes.
>
> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz <mailto:marc...@gmail.com>> a écrit :
> Think of a channel as existing for the lifetime of a particular data stream,
> and not have it be associated with either producer or consumer. Here's an
> example:
>
> https://play.golang.org/p/aEAXXtz2X1g <https://play.golang.org/p/aEAXXtz2X1g>
>
> The channel here is closed after all producers have exited, and all consumers
> continue to run until the channel is drained of data.
>
> The producers are managed by something somewhere in your code - and that is
> the scope at which it makes sense to create channel ownership. I've used a
> waitgroup to ensure that the channel is closed after all producers exit, but
> you can use whatever barrier construct you want.
>
> Even if you must have a channel per producer, you can safely close the
> producer side, without notifying the downstream about this. The example early
> in the thread uses multiple channels, with one channel being used to signal
> that the producers should exit. Channels aren't really the right model for
> this, you want a thread safe flag of some sort. For example:
>
> var exitFlag uint64
> func producer(chan data int, wg *sync.WaitGroup) {
> defer wg.Done()
> for {
> shouldExit := atomic.LoadUint64()
> if shouldExit == 1 {
> return
> }
> chan <- rand.Intn(100)
> }
> }
>
> Here's 10 producers and 3 consumers sharing a channel and closing it safely
> upon receiving an exit flag:
> https://play.golang.org/p/RiKi1PGVSvF <https://play.golang.org/p/RiKi1PGVSvF>
>
> -- Marcin
>
> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara <mailto:l...@leopoldolara.com>> wrote:
> I do not think priority select is *necessary*, it could be a nice addition if
> the performance does not change.
>
> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
> Hi Robert,
>
> From the article: """To bound more the problem, in my case, you control the
> writers but not the readers"""
>
> So what I was trying to do was to be able to close, with mutiple writers,
> while being transparent for the readers. The readers only need to read as
> usual form the channel.
>
> For example, if you want to write a library where the user just reads from a
> channel, this is an approach I found where the user of the lirbary deos nto
> have to do anything special. Of course, there might be another solution, but
> if you need to modify the reader we are talking about a different problem.
>
> Cheers!!
>
> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
> A better solution is to wrap the writes using a
Re: [go-nuts] An old problem: lack of priority select cases
I will write and post this evening. -Original Message-
From: T L
Sent: Aug 28, 2019 1:11 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 1:49:51 PM UTC-4, Robert Engels wrote:As I said in another email, using a RWMutex makes the multiple senders problem easily solvable. Grab the Read lock when writing, and the Write lock when closing. Set a 'closed' flag during Close that is checked during the write.Could you show a piece of code for easily understanding?-Original Message-
From: T L
Sent: Aug 28, 2019 12:37 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote:And what I was trying to say is that request is inherently racy.You can already do priority selects. see https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic though to use buffered channels. Pretty easy to wrap this in a function that takes N channels.This is not the priority I expected. Could you make an example based on my code in the first comment? so that I can understand it easily.In fact, I have verbose version which doesn't need priority select cases.It is an acceptable solution. But there are many other more complex cases, such as multiple senders.I haven't found an acceptable solution for such complex cases.import "math/rand"type Producer struct { data chan int closing chan struct{} canSafeClose chan struct{}}func NewProducer() *Producer { p := { data: make(chan int), closing: make(chan struct{}), canSafeClose: make(chan struct{}), } go p.run() return p}func (p *Produce) Stream() chan int { return p.data}func (p *Producer) run() { for { select { case <-p.closing: close(p.canSafeClose) return default: } select { case <-p.closing: close(p.canSafeClose) return case p.data <- rand.Int(): } }}func (p *Producer) Close() { close(p.closed) <-p.canSafeClose close(p.data)}func main() { p := NewProducer() for n := p.Stream() { // use n ... }}-Original Message-
From: T L
Sent: Aug 28, 2019 11:43 AM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:That's inherently racy - since between when the runtime determines the channel is OK for writing, another routine can close the channel before the write is attempted - so "priorities" won't help.I understand this. What I mean is it would be great to support priority select cases.-Original Message-
From: T L
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts
Subject: [go-nuts] An old problem: lack of priority select cases
The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo channels are flexible, but in practice, I often encountered some situations in which channel are hard to use.Given an example:import "math/rand"type Producer struct { data chan int closed chan struct{}}func NewProducer() *Producer { p := { data: make(chan int), closed: make(chan struct{}), } go p.run() return p}func (p *Produce) Stream() chan int { return p.data}func (p *Producer) run() { for { // If non-blocking cases are selected by their appearance order, // then the following slect block is a perfect use. select { case(0) <-p.closed: return case p.data <- rand.Int(): } }}func (p *Produce) Clsoe() { close(p.closed) close(p.data)}func main() { p := NewProducer() for n := p.Stream() { // use n ... }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?
--
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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,
Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 1:49:51 PM UTC-4, Robert Engels wrote:
>
> As I said in another email, using a RWMutex makes the multiple senders
> problem easily solvable. Grab the Read lock when writing, and the Write
> lock when closing. Set a 'closed' flag during Close that is checked during
> the write.
>
Could you show a piece of code for easily understanding?
>
> -Original Message-
> From: T L
> Sent: Aug 28, 2019 12:37 PM
> To: golang-nuts
> Subject: Re: [go-nuts] An old problem: lack of priority select cases
>
>
>
> On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote:
>>
>> And what I was trying to say is that request is inherently racy.
>>
>> You can already do priority selects. see
>> https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic
>> though to use buffered channels. Pretty easy to wrap this in a function
>> that takes N channels.
>>
>
> This is not the priority I expected. Could you make an example based on my
> code in the first comment? so that I can understand it easily.
> In fact, I have verbose version which doesn't need priority select cases.
> It is an acceptable solution. But there are many other more complex cases,
> such as multiple senders.
> I haven't found an acceptable solution for such complex cases.
>
> import "math/rand"
>
> type Producer struct {
> data chan int
> closing chan struct{}
> canSafeClose chan struct{}
> }
>
> func NewProducer() *Producer {
> p := {
> data: make(chan int),
> closing: make(chan struct{}),
> canSafeClose: make(chan struct{}),
> }
>
> go p.run()
>
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> select {
> case <-p.closing:
> close(p.canSafeClose)
> return
> default:
> }
>
> select {
> case <-p.closing:
> close(p.canSafeClose)
> return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Producer) Close() {
> close(p.closed)
> <-p.canSafeClose
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
>> -Original Message-
>> From: T L
>> Sent: Aug 28, 2019 11:43 AM
>> To: golang-nuts
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases
>>
>>
>>
>> On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:
>>>
>>> That's inherently racy - since between when the runtime determines the
>>> channel is OK for writing, another routine can close the channel before the
>>> write is attempted - so "priorities" won't help.
>>>
>>
>> I understand this. What I mean is it would be great to support priority
>> select cases.
>>
>>>
>>> -Original Message-
>>> From: T L
>>> Sent: Aug 28, 2019 11:06 AM
>>> To: golang-nuts
>>> Subject: [go-nuts] An old problem: lack of priority select cases
>>>
>>> The old thread:
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p := {
>>> data: make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>>
>>> go p.run()
>>>
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>&g
Re: [go-nuts] An old problem: lack of priority select cases
As I said in another email, using a RWMutex makes the multiple senders problem easily solvable. Grab the Read lock when writing, and the Write lock when closing. Set a 'closed' flag during Close that is checked during the write.-Original Message-
From: T L
Sent: Aug 28, 2019 12:37 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote:And what I was trying to say is that request is inherently racy.You can already do priority selects. see https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic though to use buffered channels. Pretty easy to wrap this in a function that takes N channels.This is not the priority I expected. Could you make an example based on my code in the first comment? so that I can understand it easily.In fact, I have verbose version which doesn't need priority select cases.It is an acceptable solution. But there are many other more complex cases, such as multiple senders.I haven't found an acceptable solution for such complex cases.import "math/rand"type Producer struct { data chan int closing chan struct{} canSafeClose chan struct{}}func NewProducer() *Producer { p := { data: make(chan int), closing: make(chan struct{}), canSafeClose: make(chan struct{}), } go p.run() return p}func (p *Produce) Stream() chan int { return p.data}func (p *Producer) run() { for { select { case <-p.closing: close(p.canSafeClose) return default: } select { case <-p.closing: close(p.canSafeClose) return case p.data <- rand.Int(): } }}func (p *Producer) Close() { close(p.closed) <-p.canSafeClose close(p.data)}func main() { p := NewProducer() for n := p.Stream() { // use n ... }}-Original Message-
From: T L
Sent: Aug 28, 2019 11:43 AM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:That's inherently racy - since between when the runtime determines the channel is OK for writing, another routine can close the channel before the write is attempted - so "priorities" won't help.I understand this. What I mean is it would be great to support priority select cases.-Original Message-
From: T L
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts
Subject: [go-nuts] An old problem: lack of priority select cases
The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo channels are flexible, but in practice, I often encountered some situations in which channel are hard to use.Given an example:import "math/rand"type Producer struct { data chan int closed chan struct{}}func NewProducer() *Producer { p := { data: make(chan int), closed: make(chan struct{}), } go p.run() return p}func (p *Produce) Stream() chan int { return p.data}func (p *Producer) run() { for { // If non-blocking cases are selected by their appearance order, // then the following slect block is a perfect use. select { case(0) <-p.closed: return case p.data <- rand.Int(): } }}func (p *Produce) Clsoe() { close(p.closed) close(p.data)}func main() { p := NewProducer() for n := p.Stream() { // use n ... }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?
--
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscr
Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote:
>
> And what I was trying to say is that request is inherently racy.
>
> You can already do priority selects. see
> https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic
> though to use buffered channels. Pretty easy to wrap this in a function
> that takes N channels.
>
This is not the priority I expected. Could you make an example based on my
code in the first comment? so that I can understand it easily.
In fact, I have verbose version which doesn't need priority select cases.
It is an acceptable solution. But there are many other more complex cases,
such as multiple senders.
I haven't found an acceptable solution for such complex cases.
import "math/rand"
type Producer struct {
data chan int
closing chan struct{}
canSafeClose chan struct{}
}
func NewProducer() *Producer {
p := {
data: make(chan int),
closing: make(chan struct{}),
canSafeClose: make(chan struct{}),
}
go p.run()
return p
}
func (p *Produce) Stream() chan int {
return p.data
}
func (p *Producer) run() {
for {
select {
case <-p.closing:
close(p.canSafeClose)
return
default:
}
select {
case <-p.closing:
close(p.canSafeClose)
return
case p.data <- rand.Int():
}
}
}
func (p *Producer) Close() {
close(p.closed)
<-p.canSafeClose
close(p.data)
}
func main() {
p := NewProducer()
for n := p.Stream() {
// use n ...
}
}
> -Original Message-
> From: T L
> Sent: Aug 28, 2019 11:43 AM
> To: golang-nuts
> Subject: Re: [go-nuts] An old problem: lack of priority select cases
>
>
>
> On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:
>>
>> That's inherently racy - since between when the runtime determines the
>> channel is OK for writing, another routine can close the channel before the
>> write is attempted - so "priorities" won't help.
>>
>
> I understand this. What I mean is it would be great to support priority
> select cases.
>
>>
>> -Original Message-
>> From: T L
>> Sent: Aug 28, 2019 11:06 AM
>> To: golang-nuts
>> Subject: [go-nuts] An old problem: lack of priority select cases
>>
>> The old thread:
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := {
>> data: make(chan int),
>> closed: make(chan struct{}),
>> }
>>
>> go p.run()
>>
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to
>> implement the code
>> satisfying the above listed requirements. The final implementation is
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>> --
>> 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 golan...@googlegroups.com.
>> To
Re: [go-nuts] An old problem: lack of priority select cases
And what I was trying to say is that request is inherently racy.You can already do priority selects. see https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic though to use buffered channels. Pretty easy to wrap this in a function that takes N channels.-Original Message-
From: T L
Sent: Aug 28, 2019 11:43 AM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:That's inherently racy - since between when the runtime determines the channel is OK for writing, another routine can close the channel before the write is attempted - so "priorities" won't help.I understand this. What I mean is it would be great to support priority select cases.-Original Message-
From: T L
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts
Subject: [go-nuts] An old problem: lack of priority select cases
The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo channels are flexible, but in practice, I often encountered some situations in which channel are hard to use.Given an example:import "math/rand"type Producer struct { data chan int closed chan struct{}}func NewProducer() *Producer { p := { data: make(chan int), closed: make(chan struct{}), } go p.run() return p}func (p *Produce) Stream() chan int { return p.data}func (p *Producer) run() { for { // If non-blocking cases are selected by their appearance order, // then the following slect block is a perfect use. select { case(0) <-p.closed: return case p.data <- rand.Int(): } }}func (p *Produce) Clsoe() { close(p.closed) close(p.data)}func main() { p := NewProducer() for n := p.Stream() { // use n ... }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?
--
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1979231886.5340.1567012298824%40wamui-bison.atl.sa.earthlink.net.
Re: [go-nuts] An old problem: lack of priority select cases
On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:
>
> That's inherently racy - since between when the runtime determines the
> channel is OK for writing, another routine can close the channel before the
> write is attempted - so "priorities" won't help.
>
I understand this. What I mean is it would be great to support priority
select cases.
>
> -Original Message-
> From: T L
> Sent: Aug 28, 2019 11:06 AM
> To: golang-nuts
> Subject: [go-nuts] An old problem: lack of priority select cases
>
> The old thread:
> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>
> Go channels are flexible, but in practice, I often encountered some
> situations in which channel are hard to use.
> Given an example:
>
> import "math/rand"
>
> type Producer struct {
> data chan int
> closed chan struct{}
> }
>
> func NewProducer() *Producer {
> p := {
> data: make(chan int),
> closed: make(chan struct{}),
> }
>
> go p.run()
>
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> // If non-blocking cases are selected by their appearance order,
> // then the following slect block is a perfect use.
> select {
> case(0) <-p.closed: return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Produce) Clsoe() {
> close(p.closed)
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
> If the first case in the select block in the above example has a higher
> priority than the second one,
> then coding will be much happier for the use cases like the above one.
>
> In short, the above use case requires:
> * for receivers, data streaming end is notified by the close of a channel.
> * for senders, data will never be sent to closed channel.
>
> But, as Go 1 doesn't support priority select cases, it is much tedious to
> implement the code
> satisfying the above listed requirements. The final implementation is
> often very ugly and inefficient.
>
> Does anyone else also experience the pain?
>
> --
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.com.
Re: [go-nuts] An old problem: lack of priority select cases
That's inherently racy - since between when the runtime determines the channel is OK for writing, another routine can close the channel before the write is attempted - so "priorities" won't help.-Original Message-
From: T L
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts
Subject: [go-nuts] An old problem: lack of priority select cases
The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo channels are flexible, but in practice, I often encountered some situations in which channel are hard to use.Given an example:import "math/rand"type Producer struct { data chan int closed chan struct{}}func NewProducer() *Producer { p := { data: make(chan int), closed: make(chan struct{}), } go p.run() return p}func (p *Produce) Stream() chan int { return p.data}func (p *Producer) run() { for { // If non-blocking cases are selected by their appearance order, // then the following slect block is a perfect use. select { case(0) <-p.closed: return case p.data <- rand.Int(): } }}func (p *Produce) Clsoe() { close(p.closed) close(p.data)}func main() { p := NewProducer() for n := p.Stream() { // use n ... }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1664469656.4611.1567010186688%40wamui-bison.atl.sa.earthlink.net.
