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

[T L]

On Saturday, October 5, 2019 at 6:28:37 AM UTC-4, ohir wrote:
>
> On Fri, 4 Oct 2019 15:15:30 -0700 (PDT) 
> T L > wrote: 
>
> > > If your out <-v must be dependent of ctx.Done not being ready you 
> > > must resolve this dependency by other means. Eg. by selecting for it 
> > > in separate select before. 
> > >   
>
> > It is not a must. It just tries to select ctx.Done if possible. 
> > In fact, if the two evens are independent with each other, 
> > there is no way to absolutely ensure the must. 
>
> If it is not a must, then introducing an order at best is void (of no use) 
> at worst it makes sure for a race condition by its very presence. 
>
> For coming together events A and B that are independent: 
>
> - proceeding them in either order A, B or in order B, A should result 
> in the same final state as if they came in said order. Hence select's 
> case ordering is unnecessary. 
>
> - otherwise (that final state depends on order) we have a dependency and 
> the 
> select switch, by language design, is not the right construct to write 
> this 
> dependency down. 
>
> FYI, AFAIR: the "1+default" select case is optimized by the compiler, so 
> now it is more 
> efficient to have "priority" written explicit than to have more than one 
> case in 
> a select (what turns on all the heavy machinery of a full select block). 
>

I do agree. I really ever benchmarked the difference, the two-select-blocks 
version
only consumes about 5% more CPU. So, for this use case, the main benefit of
supporting priority-case-order select block is it makes code look less 
verbose.

As for another use case shown in the first comment, 

select {
case <-done: return
case queue <- data:
}

In fact, the code shown in that comment is not perfect, because in other 
goroutines,
the following two lines

close(done)
close(queue)

might present a different order from they look in code. (I didn't find any 
official Go
documentation makes the guarantee that they will be closed by their 
appearance order in code.)

But if there is a way which can guarantee that "done" will always be closed 
before "queue"
(in the views of any goroutines), then

select(ordered) {
case <-done: return
case queue <- data:
}

can be executed safely in multiple goroutines concurrently.
This will simplify the implementations for some situations.

Under the current select mechanism, without supporting priority-case-order 
select block,
programmers need to make more effort to implement the same situations.
(Maybe this is not bad, as programing with channels is really fun. ;D)

 

>
> Hope this helps, 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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/192244b6-61d1-43c5-9b16-992a3d02f756%40googlegroups.com.

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

[Wojciech S. Czarnecki]

On Fri, 4 Oct 2019 15:15:30 -0700 (PDT)
T L  wrote:

> > If your out <-v must be dependent of ctx.Done not being ready you 
> > must resolve this dependency by other means. Eg. by selecting for it 
> > in separate select before. 
> >  

> It is not a must. It just tries to select ctx.Done if possible.
> In fact, if the two evens are independent with each other,
> there is no way to absolutely ensure the must.

If it is not a must, then introducing an order at best is void (of no use)
at worst it makes sure for a race condition by its very presence.

For coming together events A and B that are independent:

- proceeding them in either order A, B or in order B, A should result
in the same final state as if they came in said order. Hence select's
case ordering is unnecessary.

- otherwise (that final state depends on order) we have a dependency and the
select switch, by language design, is not the right construct to write this
dependency down.

FYI, AFAIR: the "1+default" select case is optimized by the compiler, so now it 
is more
efficient to have "priority" written explicit than to have more than one case in
a select (what turns on all the heavy machinery of a full select block).

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20191005122810.11063fab%40zuzia.

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

[Wojciech S. Czarnecki]

On Fri, 4 Oct 2019 15:42:35 -0700
Kurtis Rader  wrote:

> > On Fri, Oct 4, 2019 at 3:15 PM T L  wrote:
> > [...]
> Please, drop it. You don't know what you're talking about. I've been amazed
> at how patient everyone has been.

We need this kind of discussions and arguments. It prepares us to deal with
problems of understanding that junior programmers may have,
or even to deal with our own skewed understandings of the foggy corners
of the language.

> > [...]
> I think it's time to be more blunt in pointing out you don't understand
> concurrency and independent events.

Even if mr Tapir really does not, he for sure would not be alone, so we all
benefit from his questioning the Emperor's wear. So please don't be rude
to him.

TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20191005104629.11371341%40zuzia.

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

[T L]

> Please, drop it. You don't know what you're talking about. I've been 
amazed at how patient everyone has been. I think it's time to be more blunt 
in pointing out you don't understand concurrency and independent events.

Maybe. But you don't know I'm talking about for sure.

-- 
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/6521f318-b608-43f6-a15b-48c459bcd376%40googlegroups.com.

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

[Kurtis Rader]

Please, drop it. You don't know what you're talking about. I've been amazed
at how patient everyone has been. I think it's time to be more blunt in
pointing out you don't understand concurrency and independent events.

On Fri, Oct 4, 2019 at 3:15 PM T L  wrote:

>
>
> On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote:
>>
>> On Fri, 4 Oct 2019 13:52:19 -0700 (PDT)
>> T L  wrote:
>>
>> > One priority-order select block is not only cleaner than two
>> random-order
>> > select blocks, but also more efficient.
>>
>> It is neither.
>>
>> 1. It is not cleaner, because you would need to somehow denote
>> priorities.
>> If you think now about "in written order", you should think of the most
>> frequent
>> cases that you do not want to have all five, ten, twenty cases be
>> serviced
>> on order. Not to mention that down the road someone might introduce an
>> unnoticeable bug for pure aesthetic reasons.
>>
>> 2. It is not more efficient, it is less efficient because every select
>> operation
>> would need at least a "priority comparison" op, or - in general case - a
>> sort
>> op, because not only two channels can be ready, it may happen that all of
>> them will. This would have to run for every select then, unless
>> introduced by a "select_with_priorities" keyword.
>>
>>
> select(ordered)  {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
>
> is undoubtedly more efficient than
>
> select(randomized) {
> case <-ctx.Done():
> return ctx.Err()
> default:
> }
> select(randomized)  {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
>
> Not only one less try-receive operation is saved,
> but also is the step 2 described in
> https://go101.org/article/channel.html#select-implementation saved.
>
>
>
>> 3. Others tried to no avail, I will too in other words:
>>
>> The select switch is deliberately randomized because language creators
>> envisioned that otherwise someone would be "smart" and will use
>> ordering to impose a **dependency** where it should not be made.
>>
>> Channel operations serviced by select are treated as sourced
>> from **independent** events. Period.
>>
>> If your out <-v must be dependent of ctx.Done not being ready you
>> must resolve this dependency by other means. Eg. by selecting for it
>> in separate select before.
>>
>
> It is not a must. It just tries to select ctx.Done if possible.
> In fact, if the two evens are independent with each other,
> there is no way to absolutely ensure the must.
>
>
>>
>> Hope this helps,
>>
>
> You can read the first comment in this thread for another use case of 
> priority-order
> select block.
>
>
>>
>> --
>> Wojciech S. Czarnecki
>>  << ^oo^ >> OHIR-RIPE
>>
> --
> 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/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9NnBkz0jCcXM7x%3D4Ms6rw0L%2BmrWGsknD3_kKM_9mMnzw%40mail.gmail.com.

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

[T L]

On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote:
>
> On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) 
> T L > wrote: 
>
> > One priority-order select block is not only cleaner than two 
> random-order 
> > select blocks, but also more efficient. 
>
> It is neither. 
>
> 1. It is not cleaner, because you would need to somehow denote priorities. 
> If you think now about "in written order", you should think of the most 
> frequent 
> cases that you do not want to have all five, ten, twenty cases be serviced 
> on order. Not to mention that down the road someone might introduce an 
> unnoticeable bug for pure aesthetic reasons. 
>
> 2. It is not more efficient, it is less efficient because every select 
> operation 
> would need at least a "priority comparison" op, or - in general case - a 
> sort 
> op, because not only two channels can be ready, it may happen that all of 
> them will. This would have to run for every select then, unless 
> introduced by a "select_with_priorities" keyword. 
>
>
select(ordered)  {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}

is undoubtedly more efficient than 

select(randomized) {
case <-ctx.Done():
return ctx.Err()
default:
}
select(randomized)  {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}

Not only one less try-receive operation is saved,
but also is the step 2 described in 
https://go101.org/article/channel.html#select-implementation saved.

 

> 3. Others tried to no avail, I will too in other words: 
>
> The select switch is deliberately randomized because language creators 
> envisioned that otherwise someone would be "smart" and will use 
> ordering to impose a **dependency** where it should not be made. 
>
> Channel operations serviced by select are treated as sourced 
> from **independent** events. Period. 
>
> If your out <-v must be dependent of ctx.Done not being ready you 
> must resolve this dependency by other means. Eg. by selecting for it 
> in separate select before. 
>

It is not a must. It just tries to select ctx.Done if possible.
In fact, if the two evens are independent with each other,
there is no way to absolutely ensure the must.
 

>
> Hope this helps, 
>

You can read the first comment in this thread for another use case of 
priority-order 
select block.
 

>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com.

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

[Wojciech S. Czarnecki]

On Fri, 4 Oct 2019 13:52:19 -0700 (PDT)
T L  wrote:

> One priority-order select block is not only cleaner than two random-order
> select blocks, but also more efficient.

It is neither. 

1. It is not cleaner, because you would need to somehow denote priorities.
If you think now about "in written order", you should think of the most frequent
cases that you do not want to have all five, ten, twenty cases be serviced
on order. Not to mention that down the road someone might introduce an
unnoticeable bug for pure aesthetic reasons.

2. It is not more efficient, it is less efficient because every select operation
would need at least a "priority comparison" op, or - in general case - a sort
op, because not only two channels can be ready, it may happen that all of
them will. This would have to run for every select then, unless 
introduced by a "select_with_priorities" keyword.

3. Others tried to no avail, I will too in other words:

The select switch is deliberately randomized because language creators
envisioned that otherwise someone would be "smart" and will use
ordering to impose a **dependency** where it should not be made.

Channel operations serviced by select are treated as sourced
from **independent** events. Period. 

If your out <-v must be dependent of ctx.Done not being ready you
must resolve this dependency by other means. Eg. by selecting for it
in separate select before. 

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20191004233941.0b5c516e%40zuzia.

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

[Robert Engels]

But even the two select blocks does not really make a difference. I have shared code that did this previously.For another example, think of two channels A and B. A is the high priority channel where all events should be processed before B channel events - this is especially important considering that A events can be processed in 1 ms, and B events take 60 seconds.So, as soon as you start processing a B event - you have delayed the processing of a "just after" A event by 60 seconds... probably not what you want. So you either need to be able to stop the processing of B, or you need to process them "concurrently" (this is a simplification of how to actually accomplish this).This is why if closing the channel is independent of the processing of the channel, you need external synchronization and/or ordering.Are there workloads where the A and B channels are always ready at the same time, probably... but if you ALWAYS processed A first - eventually B would run out of queue/memory space - and either deadlock or crash...I will reiterate - your thinking on this problem is incorrect, which is why the solution you propose is of limited usefulness. Still, if you really want this, it is simple to write a function 'selectUsingPriority(A,B chan). But if you don't fully understand what I am saying, you are going to have obscure reliability problems in production if you use it.-Original Message-
From: T L 
Sent: Oct 4, 2019 3:52 PM
To: golang-nuts 
Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 4:38:36 PM UTC-4, Marcin Romaszewicz wrote:What he's trying to say is that it is pointless to order select cases in this example, because it is impossible to guarantee ordering in an asynchronous system.You have two asynchronous data streams, ctx.Done() and "v", in that example above.Generally, those select cases will happen one by one, as those asynchronous channels deliver data. If "v" is ready first, shortly before ctx.Done(), then v will be selected first, followed by ctx.Done(). It doesn't matter that ctx.Done() wants to be higher priority, "v" arrived first, before ctx.Done() was posted, so it's handled first. If ctx.Done() happens first, the reverse happens. The only interesting case is when both "v" and ctx.Done() are ready at the same time, which will be unlikely in practice.If ctx.Done() and "v" happen together, so that both cases of that select statement are available simultaneously, then sure, you can order them, but this will happen very infrequently, and you still MUST handle the case where "v" happens first, very close to ctx.Done(). So, if you MUST handle this case, you don't really need to bother with statement priority, since if your code is written well, this ordering won't matter. ctx.Done() might happen while you're in the middle of handling "v", for example.This is not frequently, but not rare. The desire to have priority to select statements presumes that you have several cases happen at the same time, which isn't how this will generally work. If you want to order things in a select, you have to change how it behaves, and order events within a particular time window. Say you write a poller which samples the event queue every second. If you do this, then sure, you can order things however you want, but the cost you pay is that second of buffering latency.Yes, select case priority tries to always select one case of the two caseswhen both the two cases are available. Without this feature, to achievethis goal, we often need two select blocks (sorry, I mis-typed  select block as  select case in my last comment). One priority-order select block is not only cleaner than two random-order select blocks, but also more efficient.On Fri, Oct 4, 2019 at 1:19 PM T L <tapi...@gmail.com> wrote:On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:Because ctx.Done() and v being ready for read are independent events. You can not impose ordering on them unless there is an outer mutex that both events are subject to.As an aside, this is why I think the best 'concurrent software' developers are those that have been exposed to at least some hardware design. Many programmers think in terms of 1 and 0 and everything being ordered. This is certainly not the case in hardware, nor concurrent software. (For example, in computer hardware, the clock/sync line is what is used as the outer controlling event, but still things like propagation times, etc. make even this simple statement not fully correct).Still not understanding what you new saying. ;DAgain, select case priority enables use to deduce two select casesto one select case in coding in many scenarios.This often leads to cleaner code, avoid can avoid the harm causedby missing a try-receive select case. -----Original Message-
From: T L 
Sent: Oct 4,

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

[T L]

On Friday, October 4, 2019 at 4:38:36 PM UTC-4, Marcin Romaszewicz wrote:
>
> What he's trying to say is that it is pointless to order select cases in 
> this example, because it is impossible to guarantee ordering in an 
> asynchronous system.
>
> You have two asynchronous data streams, ctx.Done() and "v", in that 
> example above.
>
> Generally, those select cases will happen one by one, as those 
> asynchronous channels deliver data. If "v" is ready first, shortly before 
> ctx.Done(), then v will be selected first, followed by ctx.Done(). It 
> doesn't matter that ctx.Done() wants to be higher priority, "v" arrived 
> first, before ctx.Done() was posted, so it's handled first. If ctx.Done() 
> happens first, the reverse happens. The only interesting case is when both 
> "v" and ctx.Done() are ready at the same time, which will be unlikely in 
> practice.
>
> If ctx.Done() and "v" happen together, so that both cases of that select 
> statement are available simultaneously, then sure, you can order them, but 
> this will happen very infrequently, and you still MUST handle the case 
> where "v" happens first, very close to ctx.Done(). So, if you MUST handle 
> this case, you don't really need to bother with statement priority, since 
> if your code is written well, this ordering won't matter. ctx.Done() might 
> happen while you're in the middle of handling "v", for example.
>
>
This is not frequently, but not rare.
 

> The desire to have priority to select statements presumes that you have 
> several cases happen at the same time, which isn't how this will generally 
> work. If you want to order things in a select, you have to change how it 
> behaves, and order events within a particular time window. Say you write a 
> poller which samples the event queue every second. If you do this, then 
> sure, you can order things however you want, but the cost you pay is that 
> second of buffering latency.
>

Yes, select case priority tries to always select one case of the two cases
when both the two cases are available. Without this feature, to achieve
this goal, we often need two select blocks (sorry, I mis-typed select block
as select case in my last comment). 

One priority-order select block is not only cleaner than two random-order
select blocks, but also more efficient.

>
>
> On Fri, Oct 4, 2019 at 1:19 PM T L > 
> wrote:
>
>>
>>
>> On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>>>
>>> Because ctx.Done() and v being ready for read are independent events. 
>>> You can not impose ordering on them unless there is an outer mutex that 
>>> both events are subject to.
>>>
>>> As an aside, this is why I think the best 'concurrent software' 
>>> developers are those that have been exposed to at least some hardware 
>>> design. Many programmers think in terms of 1 and 0 and everything being 
>>> ordered. This is certainly not the case in hardware, nor concurrent 
>>> software. (For example, in computer hardware, the clock/sync line is what 
>>> is used as the outer controlling event, but still things like propagation 
>>> times, etc. make even this simple statement not fully correct).
>>>
>>>
>> Still not understanding what you new saying. ;D
>>
>> Again, select case priority enables use to deduce two select cases
>> to one select case in coding in many scenarios.
>> This often leads to cleaner code, avoid can avoid the harm caused
>> by missing a try-receive select case.
>>
>>  
>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Oct 4, 2019 2:44 PM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>>>
>>>> You still are not understanding  proper concurrent design. Priority 
>>>> select cases do not matter in the case of asynchronous external events. 
>>>>
>>>
>>> It at least avoids code verbosity and improves code quantity..
>>>
>>> BTW, I don't understand what you said. Could you elaborate more?
>>>
>>>
>>>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>>>
>>>> 
>>>> I just found an example in the "context" package docs:
>>>>
>>>> //  // Stream generates values with DoSomething and sends them to out
>>>> //  // until DoS

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

[Marcin Romaszewicz]

What he's trying to say is that it is pointless to order select cases in
this example, because it is impossible to guarantee ordering in an
asynchronous system.

You have two asynchronous data streams, ctx.Done() and "v", in that example
above.

Generally, those select cases will happen one by one, as those asynchronous
channels deliver data. If "v" is ready first, shortly before ctx.Done(),
then v will be selected first, followed by ctx.Done(). It doesn't matter
that ctx.Done() wants to be higher priority, "v" arrived first, before
ctx.Done() was posted, so it's handled first. If ctx.Done() happens first,
the reverse happens. The only interesting case is when both "v" and
ctx.Done() are ready at the same time, which will be unlikely in practice.

If ctx.Done() and "v" happen together, so that both cases of that select
statement are available simultaneously, then sure, you can order them, but
this will happen very infrequently, and you still MUST handle the case
where "v" happens first, very close to ctx.Done(). So, if you MUST handle
this case, you don't really need to bother with statement priority, since
if your code is written well, this ordering won't matter. ctx.Done() might
happen while you're in the middle of handling "v", for example.

The desire to have priority to select statements presumes that you have
several cases happen at the same time, which isn't how this will generally
work. If you want to order things in a select, you have to change how it
behaves, and order events within a particular time window. Say you write a
poller which samples the event queue every second. If you do this, then
sure, you can order things however you want, but the cost you pay is that
second of buffering latency.


On Fri, Oct 4, 2019 at 1:19 PM T L  wrote:

>
>
> On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>>
>> Because ctx.Done() and v being ready for read are independent events. You
>> can not impose ordering on them unless there is an outer mutex that both
>> events are subject to.
>>
>> As an aside, this is why I think the best 'concurrent software'
>> developers are those that have been exposed to at least some hardware
>> design. Many programmers think in terms of 1 and 0 and everything being
>> ordered. This is certainly not the case in hardware, nor concurrent
>> software. (For example, in computer hardware, the clock/sync line is what
>> is used as the outer controlling event, but still things like propagation
>> times, etc. make even this simple statement not fully correct).
>>
>>
> Still not understanding what you new saying. ;D
>
> Again, select case priority enables use to deduce two select cases
> to one select case in coding in many scenarios.
> This often leads to cleaner code, avoid can avoid the harm caused
> by missing a try-receive select case.
>
>
>
>> -Original Message-
>> From: T L
>> Sent: Oct 4, 2019 2:44 PM
>> To: golang-nuts
>> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases
>>
>>
>>
>> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>>
>>> You still are not understanding  proper concurrent design. Priority
>>> select cases do not matter in the case of asynchronous external events.
>>>
>>
>> It at least avoids code verbosity and improves code quantity..
>>
>> BTW, I don't understand what you said. Could you elaborate more?
>>
>>
>>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>>
>>> 
>>> I just found an example in the "context" package docs:
>>>
>>> //  // Stream generates values with DoSomething and sends them to out
>>> //  // until DoSomething returns an error or ctx.Done is closed.
>>> //  func Stream(ctx context.Context, out chan<- Value) error {
>>> //  for {
>>> //  v, err := DoSomething(ctx)
>>> //  if err != nil {
>>> //  return err
>>> //  }
>>> //  select {
>>> //  case <-ctx.Done():
>>> //  return ctx.Err()
>>> //  case out <- v:
>>> //  }
>>> //  }
>>> //  }
>>>
>>> It looks the send "out <- v" still has a possibility to be executed,
>>> even if "ctx.Done()" is closed.
>>> But if Go supports select case priority, then this will never happen.
>>>
>>>
>>>
>>> On

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

[T L]

On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>
> Because ctx.Done() and v being ready for read are independent events. You 
> can not impose ordering on them unless there is an outer mutex that both 
> events are subject to.
>
> As an aside, this is why I think the best 'concurrent software' developers 
> are those that have been exposed to at least some hardware design. Many 
> programmers think in terms of 1 and 0 and everything being ordered. This is 
> certainly not the case in hardware, nor concurrent software. (For example, 
> in computer hardware, the clock/sync line is what is used as the outer 
> controlling event, but still things like propagation times, etc. make even 
> this simple statement not fully correct).
>
>
Still not understand what you new saying means. ;D

Again, select case priority enables use to deduce two select cases
to one select case in coding in many scenarios.
This often leads to cleaner code, and sometimes can avoid the harm 
caused by missing an essential try-receive select case.

 

> -Original Message- 
> From: T L 
> Sent: Oct 4, 2019 2:44 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases 
>
>
>
> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>
>> You still are not understanding  proper concurrent design. Priority 
>> select cases do not matter in the case of asynchronous external events. 
>>
>
> It at least avoids code verbosity and improves code quantity..
>
> BTW, I don't understand what you said. Could you elaborate more?
>
>
>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>
>> 
>> I just found an example in the "context" package docs:
>>
>> //  // Stream generates values with DoSomething and sends them to out
>> //  // until DoSomething returns an error or ctx.Done is closed.
>> //  func Stream(ctx context.Context, out chan<- Value) error {
>> //   for {
>> //   v, err := DoSomething(ctx)
>> //   if err != nil {
>> //   return err
>> //   }
>> //   select {
>> //   case <-ctx.Done():
>> //   return ctx.Err()
>> //   case out <- v:
>> //   }
>> //   }
>> //  }
>>
>> It looks the send "out <- v" still has a possibility to be executed,
>> even if "ctx.Done()" is closed.
>> But if Go supports select case priority, then this will never happen.
>>
>>
>>
>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, 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 := &Producer {
>>> 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.
>>

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

[T L]

On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>
> Because ctx.Done() and v being ready for read are independent events. You 
> can not impose ordering on them unless there is an outer mutex that both 
> events are subject to.
>
> As an aside, this is why I think the best 'concurrent software' developers 
> are those that have been exposed to at least some hardware design. Many 
> programmers think in terms of 1 and 0 and everything being ordered. This is 
> certainly not the case in hardware, nor concurrent software. (For example, 
> in computer hardware, the clock/sync line is what is used as the outer 
> controlling event, but still things like propagation times, etc. make even 
> this simple statement not fully correct).
>
>
Still not understanding what you new saying. ;D

Again, select case priority enables use to deduce two select cases
to one select case in coding in many scenarios.
This often leads to cleaner code, avoid can avoid the harm caused
by missing a try-receive select case.

 

> -Original Message- 
> From: T L 
> Sent: Oct 4, 2019 2:44 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases 
>
>
>
> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>
>> You still are not understanding  proper concurrent design. Priority 
>> select cases do not matter in the case of asynchronous external events. 
>>
>
> It at least avoids code verbosity and improves code quantity..
>
> BTW, I don't understand what you said. Could you elaborate more?
>
>
>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>
>> 
>> I just found an example in the "context" package docs:
>>
>> //  // Stream generates values with DoSomething and sends them to out
>> //  // until DoSomething returns an error or ctx.Done is closed.
>> //  func Stream(ctx context.Context, out chan<- Value) error {
>> //   for {
>> //   v, err := DoSomething(ctx)
>> //   if err != nil {
>> //   return err
>> //   }
>> //   select {
>> //   case <-ctx.Done():
>> //   return ctx.Err()
>> //   case out <- v:
>> //   }
>> //   }
>> //  }
>>
>> It looks the send "out <- v" still has a possibility to be executed,
>> even if "ctx.Done()" is closed.
>> But if Go supports select case priority, then this will never happen.
>>
>>
>>
>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, 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 := &Producer {
>>> 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, d

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

[Robert Engels]

Because ctx.Done() and v being ready for read are independent events. You can not impose ordering on them unless there is an outer mutex that both events are subject to.As an aside, this is why I think the best 'concurrent software' developers are those that have been exposed to at least some hardware design. Many programmers think in terms of 1 and 0 and everything being ordered. This is certainly not the case in hardware, nor concurrent software. (For example, in computer hardware, the clock/sync line is what is used as the outer controlling event, but still things like propagation times, etc. make even this simple statement not fully correct).-Original Message-
From: T L 
Sent: Oct 4, 2019 2:44 PM
To: golang-nuts 
Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:You still are not understanding  proper concurrent design. Priority select cases do not matter in the case of asynchronous external events. It at least avoids code verbosity and improves code quantity..BTW, I don't understand what you said. Could you elaborate more?On Oct 4, 2019, at 1:46 PM, T L <tapi...@gmail.com> wrote:I just found an example in the "context" package docs://  // Stream generates values with DoSomething and sends them to out
//  // until DoSomething returns an error or ctx.Done is closed.
//  func Stream(ctx context.Context, out chan<- Value) error {
//  	for {
//  		v, err := DoSomething(ctx)
//  		if err != nil {
//  			return err
//  		}
//  		select {
//  		case <-ctx.Done():
//  			return ctx.Err()
//  		case out <- v:
//  		}
//  	}
//  }It looks the send "out <- v" still has a possibility to be executed,even if "ctx.Done()" is closed.But if Go supports select case priority, then this will never happen.On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote: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 := &Producer {        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/b7a14153-253e-43c4-bda5-96079601465f%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/77fca2e9-120d-45e0-8ae9-5d24b63827bd%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/975777479.10069.1570219711061%40wamui-aurora.atl.sa.earthlink.net.

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

[T L]

On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>
> You still are not understanding  proper concurrent design. Priority select 
> cases do not matter in the case of asynchronous external events. 
>

It at least avoids code verbosity and improves code quantity..

BTW, I don't understand what you said. Could you elaborate more?


> On Oct 4, 2019, at 1:46 PM, T L > wrote:
>
> 
> I just found an example in the "context" package docs:
>
> //  // Stream generates values with DoSomething and sends them to out
> //  // until DoSomething returns an error or ctx.Done is closed.
> //  func Stream(ctx context.Context, out chan<- Value) error {
> //for {
> //v, err := DoSomething(ctx)
> //if err != nil {
> //return err
> //}
> //select {
> //case <-ctx.Done():
> //return ctx.Err()
> //case out <- v:
> //}
> //}
> //  }
>
> It looks the send "out <- v" still has a possibility to be executed,
> even if "ctx.Done()" is closed.
> But if Go supports select case priority, then this will never happen.
>
>
>
> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, 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 := &Producer {
>> 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/b7a14153-253e-43c4-bda5-96079601465f%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/77fca2e9-120d-45e0-8ae9-5d24b63827bd%40googlegroups.com.

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

[Robert Engels]

You still are not understanding  proper concurrent design. Priority select 
cases do not matter in the case of asynchronous external events. 

> On Oct 4, 2019, at 1:46 PM, T L  wrote:
> 
> 
> I just found an example in the "context" package docs:
> 
> //  // Stream generates values with DoSomething and sends them to out
> //  // until DoSomething returns an error or ctx.Done is closed.
> //  func Stream(ctx context.Context, out chan<- Value) error {
> //for {
> //v, err := DoSomething(ctx)
> //if err != nil {
> //return err
> //}
> //select {
> //case <-ctx.Done():
> //return ctx.Err()
> //case out <- v:
> //}
> //}
> //  }
> 
> It looks the send "out <- v" still has a possibility to be executed,
> even if "ctx.Done()" is closed.
> But if Go supports select case priority, then this will never happen.
> 
> 
>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, 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 := &Producer {
>> 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/b7a14153-253e-43c4-bda5-96079601465f%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/5DB82954-56D2-455F-ADF4-02B845D52783%40ix.netcom.com.

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

[T L]

@Leo Lara

In face, you code the Mutex+WaitGroup in your code can be replaced with a 
Cond var plus a counter: https://play.golang.org/p/hVLamTjHj6J

On Wednesday, September 4, 2019 at 5:44:11 AM UTC-4, Leo Lara wrote:
>
> Hi Marcin,
>
> I think https://play.golang.org/p/RiKi1PGVSvF is basically what I do with 
> atomic operations in my blog post 
> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>  in 
> the section "Some experiments", and then using the wait group as I say 
> later in the section "The solution involves wait groups",
>
> I think it is more constrained than my final solution because:
>  + You need to make sure that all producers have started (run Add(1)) 
> before you call Close. You would need to use a mutex around Add and Wait to 
> solve this, I think now that a RWLock have the read arround Add(1) and the 
> write around Wait could be better.
>  + All writing goroutines will stay blocked until a reader reads all, 
> using a closing channel is better because you can use select and they could 
> unblock without a reader.
>
>
> On Wednesday, August 28, 2019 at 10:37:52 PM UTC+2, Marcin Romaszewicz 
> wrote:
>>
>> 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(&exitFlag)
>> 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] Re: An old problem: lack of priority select cases

[Leo Lara]

Hi Jasper,

Do you have some literature with that use. I honestly have googled: 
https://www.google.com/search?rlz=1C5CHFA_enES851ES851&biw=1280&bih=698&ei=v4lvXcnpE4_gUbmTiLgK&q=transparency+component+software+engineering&oq=transparency+component+software+engineering&gs_l=psy-ab.3...10733.11100..11571...0.2..0.196.549.0j3..01..gws-wiz...0i71j35i304i39.sGAC4ozKBlY&ved=0ahUKEwiJxe788rbkAhUPcBQKHbkJAqc4ChDh1QMICw&uact=5

and the first result I got 
https://en.wikipedia.org/wiki/Transparency_(human%E2%80%93computer_interaction)

It is kind of what I said:

"""The purpose is to shield from change all systems (or human users) on the 
other end of the interface. Confusingly, the term refers to overall 
*invisibility* of the component, it does not refer to *visibility of 
component's internals* (as in white box 
 or open 
system )

On Saturday, August 31, 2019 at 10:53:26 AM UTC+2, Jesper Louis Andersen 
wrote:
>
> On Thu, Aug 29, 2019 at 7:02 AM Leo Lara  > wrote:
>
>> Hi Michael,
>>
>> The way I always have seen "transparent" used in software engineering is, 
>> that the user of something (lirabry, service, framework, etc) can use it 
>> without knowing its internal details, just normally, and the magic is done 
>> in the thing used.
>>
>>
> People use this in the opposite form at times. That is, a transparent data 
> structure is one where you know its internal representation (and can rely 
> on that in your part of the program). In contrast an opaque data structure 
> is abstractly encapsulated: even if you know its internals, you cannot get 
> at it. Thus the latter is the former and the former is the latter compared 
> to your use.
>
>

-- 
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/554e994c-fb9b-438c-b12d-940c8f44a945%40googlegroups.com.

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

[Leo Lara]

Hi Marcin,

I think https://play.golang.org/p/RiKi1PGVSvF is basically what I do with 
atomic operations in my blog post 
https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 
in 
the section "Some experiments", and then using the wait group as I say 
later in the section "The solution involves wait groups",

I think it is more constrained than my final solution because:
 + You need to make sure that all producers have started (run Add(1)) 
before you call Close. You would need to use a mutex around Add and Wait to 
solve this, I think now that a RWLock have the read arround Add(1) and the 
write around Wait could be better.
 + All writing goroutines will stay blocked until a reader reads all, using 
a closing channel is better because you can use select and they could 
unblock without a reader.


On Wednesday, August 28, 2019 at 10:37:52 PM UTC+2, Marcin Romaszewicz 
wrote:
>
> 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(&exitFlag)
> 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 := &Producer {
> 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() {
> f

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

[Jesper Louis Andersen]

On Thu, Aug 29, 2019 at 7:02 AM Leo Lara  wrote:

> Hi Michael,
>
> The way I always have seen "transparent" used in software engineering is,
> that the user of something (lirabry, service, framework, etc) can use it
> without knowing its internal details, just normally, and the magic is done
> in the thing used.
>
>
People use this in the opposite form at times. That is, a transparent data
structure is one where you know its internal representation (and can rely
on that in your part of the program). In contrast an opaque data structure
is abstractly encapsulated: even if you know its internals, you cannot get
at it. Thus the latter is the former and the former is the latter compared
to your use.

-- 
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/CAGrdgiVtfj5oPkVYHXROyayukq9S0owzOPxgnsc4pSdTTyn9jw%40mail.gmail.com.

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

[Leo Lara]

Hi Michael,

The way I always have seen "transparent" used in software engineering is, 
that the user of something (lirabry, service, framework, etc) can use it 
without knowing its internal details, just normally, and the magic is done 
in the thing used.

To in terms of the problem I was trying to solve: being able to close a 
channel that is written by serveral goroutines, transparent property is 
that the reader or readers of the channel they just do that, without 
knowing about something else.

I think this is established in the article beginnings here: 
https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2

Regarding the priority select, I agree.

On Wednesday, August 28, 2019 at 11:10:18 PM UTC+2, 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(&exitFlag)
>> 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 
> wo

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

[Michel Levieux]

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(&exitFlag)
> 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"
>
>

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

[Marcin Romaszewicz]

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(&exitFlag)
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 := &Producer {
 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 

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

[Leo Lara]

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 := &Producer {
>>> 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/b284f880-034a-4721-8686-ef48d3e2c14c%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/aeb38a0a-8268-42d7-a8eb-ce5ef01c5380%40googlegroups.com.

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

[Leo Lara]

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 := &Producer {
>> 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/b284f880-034a-4721-8686-ef48d3e2c14c%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/405013db-74c9-474b-857c-09d3f30030c1%40googlegroups.com.

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

[T L]

On Wednesday, August 28, 2019 at 1:14:09 PM UTC-4, Robert Engels wrote:
>
> Reading the article, why not just wrap the write function in one that uses 
> panic/recover, since the write is expected to panic if the channel is 
> closed.
>

Using panic/recover is a way, but it is ugly.
 

>
> -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 := &Producer {
>> 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/b284f880-034a-4721-8686-ef48d3e2c14c%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/f6c8e515-525e-4f3c-b384-70e510b687d5%40googlegroups.com.

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

[Robert Engels]

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-52j2I 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/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 := &Producer {        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/b284f880-034a-4721-8686-ef48d3e2c14c%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/76267041.5448.1567012615707%40wamui-bison.atl.sa.earthlink.net.

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

[Robert Engels]

Reading the article, why not just wrap the write function in one that uses panic/recover, since the write is expected to panic if the channel is closed.-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-52j2I 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/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 := &Producer {        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/b284f880-034a-4721-8686-ef48d3e2c14c%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/1729188189.5384.1567012429475%40wamui-bison.atl.sa.earthlink.net.