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
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
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
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,
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
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 cases
On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robe
ase 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 M
t).
>>
>>
> 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
e 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-n
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:
, 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
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
; 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.
>>>>
&g
Hi Jasper,
Do you have some literature with that use. I honestly have googled:
erent 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 W
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
ecial. 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
t 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 - generi
;>> 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
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 connec
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
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
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
27 matches
Mail list logo
