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
@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 wh
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..
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
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
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 t
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.
>F
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
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 r
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.
Fo
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.
>
> -O
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
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 sel
27 matches
Mail list logo
