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 selec
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 possib
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
> 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
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
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, b
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
sesto 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, 2019 2:44 PM
To: golang-nuts
Subject: Re: [go-nuts] Re: An old problem: lack of priority select case
ing. ;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.
>>
>>
>>
&
ven 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 ca
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
es 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
>
tion 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 sti
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
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 DoSom
On Friday, October 4, 2019 at 2:46:36 PM UTC-4, 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 cont
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 {
//
ds
>>>> 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
>>>> differ
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..
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
>>>
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
ary
>>>> 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
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
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
>>>
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
>>
>> Th
ncapsulate 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
On Wednesday, August 28, 2019 at 1:06:07 PM UTC-4, Leo Lara wrote:
>
> 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,
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-writ
: 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
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
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 be
31 matches
Mail list logo