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

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

Re: [go-nuts] An old problem: lack of priority select cases

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

Re: [go-nuts] An old problem: lack of priority select cases

gt;> 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: >>>>>> >>>>>>

Re: [go-nuts] An old problem: lack of priority select cases

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: >>>>>>>

Re: [go-nuts] An old problem: lack of priority select cases

>>> } >>>>>> } >>>>>> >>>>>> 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 >>>>>&g

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

Re: [go-nuts] An old problem: lack of priority select cases

>>>>> 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 >>

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

Re: [go-nuts] An old problem: lack of priority select cases

t;>>>>> 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

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,

Re: [go-nuts] An old problem: lack of priority select cases

0, 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: &g

Re: [go-nuts] An old problem: lack of priority select cases

riday, 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. >>>>>>>> >>>>>>>> St

Re: [go-nuts] An old problem: lack of priority select cases

till, 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 >>>

Re: [go-nuts] An old problem: lack of priority select cases

: lack of priority select cases >>>>>> >>>>>> >>>>>> >>>>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote: >>>>>>> >>>>>>> Makes no difference

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

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

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 >>>&g

Re: [go-nuts] An old problem: lack of priority select cases

d (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 >>>> Subj

Re: [go-nuts] An old problem: lack of priority select cases

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 o

Re: [go-nuts] An old problem: lack of priority select cases

cally 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

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

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 > >

Re: [go-nuts] An old problem: lack of priority select cases

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

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: >

Re: [go-nuts] An old problem: lack of priority select cases

: 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

Re: [go-nuts] An old problem: lack of priority select cases

losed. > 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

Re: [go-nuts] An old problem: lack of priority select cases

s 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 ca

Re: [go-nuts] An old problem: lack of priority select cases

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 proble

Re: [go-nuts] An old problem: lack of priority select cases

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

Re: [go-nuts] An old problem: lack of priority select cases

ds 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 probl

Re: [go-nuts] An old problem: lack of priority select cases

Lock, 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

Re: [go-nuts] An old problem: lack of priority select cases

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 >&g

Re: [go-nuts] An old problem: lack of priority select cases

quot;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

Re: [go-nuts] An old problem: lack of priority select cases

; 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. >>>> &

Re: [go-nuts] An old problem: lack of priority select cases

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 encapsul

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

Re: [go-nuts] An old problem: lack of priority select cases

t 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 > > >

Re: [go-nuts] An old problem: lack of priority select cases

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

Re: [go-nuts] An old problem: lack of priority select cases

} } } 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:

Re: [go-nuts] An old problem: lack of priority select cases

- 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

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

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]