> need the lock on the readers)
>
> On Sep 4, 2019, at 4:55 AM, Leo Lara wrote:
>
>
>
> You should read up on how a RWLock works.
>>
>
> I am not going to answer to that ;-)
>
> About this code:
>
> https://play.golang.org/p/YOwuYFiqtlf
>
> 1. I wouldn&
wikipedia.org/wiki/White_box_(software_engineering)> or open
system <https://en.wikipedia.org/wiki/Open_system_(computing)>)""""
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
>>>>>>>>>> be atomically accessed or modified) means essentially that "having
>>>>>>>>>> multiple
>>>>>>>>>> writers being transparent to the readers", fundamentally, is not
>>
efore the desired number of iterations.
>
> On Aug 29, 2019, at 12:13 AM, Leo Lara > wrote:
>
> Hi Robert,
>
> To put you in context, it all started when I read
> https://go101.org/article/channel-closing.html , that said that it is
> impossible or at least you shouldn
haring 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 i
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 =
r(chan data int, wg *sync.WaitGroup) {
>> defer wg.Done()
>> for {
>> shouldExit := atomic.LoadUint64(&exitFlag)
>> if shouldExit == 1 {
>> return
>> }
>> chan <- rand.Intn(100)
>> }
>>
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
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
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
10 matches
Mail list logo