ok, I'm banning myself from this forum for a while. Sorry about this. I'm
not right at the moment.
On Sunday, 5 May 2019 21:55:57 UTC+2, Louki Sumirniy wrote:
>
> I think the key thing is the Add function I have written is not concurrent
> safe. I didn't intend it to be as I only had the use cas
On Sun, May 5, 2019 at 9:56 PM Louki Sumirniy
wrote:
>
> I think the key thing is the Add function I have written is not concurrent
> safe. I didn't intend it to be as I only had the use case of a single thread
> managing a worker pool, and I am pretty sure it is fine for this and for
> larger
I think the key thing is the Add function I have written is not concurrent
safe. I didn't intend it to be as I only had the use case of a single
thread managing a worker pool, and I am pretty sure it is fine for this and
for larger pools it has lower overhead of memory *and* processing.
I have
I didn't intend Add to be used concurrently, by the way. One pool one
thread for the controller.
On Sunday, 5 May 2019 21:09:40 UTC+2, Louki Sumirniy wrote:
>
> If at 13 in the else clause, if I first test for a non-nil wg.ops and
> close it if it's open, I think that stops that channel leak.
>
If at 13 in the else clause, if I first test for a non-nil wg.ops and close
it if it's open, I think that stops that channel leak.
On Sunday, 5 May 2019 18:32:14 UTC+2, Marcin Romaszewicz wrote:
>
> I've done quite a bit of MP programming over 20+ years now, and skimming
> your code, I see a nu
I've done quite a bit of MP programming over 20+ years now, and skimming
your code, I see a number of issues. There are probably a lot more that I
don't. In the latest go playground link
Line14: if "if wg.started {" has a race condition, both on accessing the
variable, and logically, in that two g
just had to drop an update, I further improved it, now when it stops it
resets itself and you can use Add again, I removed the unnecessary
positive/negative checks and condensed the Add and Done function into an
Add that can take a negative (tried to think of a better word but Modify
and Change
I figured out that the API of my design had a flaw separating starting the
goroutine and adding a new item, so as you can see in this code, I have
merged them and notice that there is basically no extraneous 'helper'
functions also:
https://play.golang.org/p/hR1sTOAwkOm
The flaw I made relates
On Sun, May 5, 2019 at 12:54 PM Louki Sumirniy
wrote:
>
> hang on, sorry to be so chatty on this but I'm learning a lot about handling
> edge cases from this, so I need to comment further
>
> ok, I got it working for that test also:
>
> https://play.golang.org/p/nd_EuCSOWto
>
> I can tell by the
On Sun, May 5, 2019 at 12:45 PM Louki Sumirniy
wrote:
>
> https://play.golang.org/p/5KwJQcTsUPg
>
> I fixed it.
Not really. You've introduced a data race.
jnml@4670:~/src/tmp> cat main.go
package main
type WaitGroup struct {
workers int
ops chan int
}
func New() *WaitGroup
Ahaha! you made a race, actually! I mean I made a race, but that code
exposed it.
I'm gonna just go away for a while. My brain doesn't really seem to be keen
on doing this kind of thinking right at this minute.
On Sunday, 5 May 2019 12:54:25 UTC+2, Louki Sumirniy wrote:
>
> hang on, sorry to be
hang on, sorry to be so chatty on this but I'm learning a lot about
handling edge cases from this, so I need to comment further
ok, I got it working for that test also:
https://play.golang.org/p/nd_EuCSOWto
I can tell by the fact you used the 'sync' keyword that you didn't in fact
test what yo
On Sun, May 5, 2019 at 12:45 PM Louki Sumirniy
wrote:
> The code you have written there has weird non-standard utf-8 code points in
> it.
It was plain ASCII only. You can verify that here:
https://groups.google.com/forum/#!original/golang-nuts/r3N6bM8YnIg/aEYX1qViBAAJ
--
You received this mes
ok, you found another flaw :) Not adding is now accounted for but waiting
twice isn't.
On Sunday, 5 May 2019 12:27:10 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
> > wrote:
>
> > Is there ANY other use case for waitgroup other than preventing a
> goroutine leak o
https://play.golang.org/p/5KwJQcTsUPg
I fixed it.
The code you have written there has weird non-standard utf-8 code points in
it. It won't make any difference whether you defer the Wait() if no Add is
called the goroutine does not start now.
On Sunday, 5 May 2019 12:27:10 UTC+2, Jan Mercl wrot
and mine is also incorrect. now it handles your test but not intended
operation. :)
On Sunday, 5 May 2019 12:25:29 UTC+2, Louki Sumirniy wrote:
>
> With your (imho incorrect) code, the following small modification defers
> starting the channel until an add has been called and passes the test:
>
On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
wrote:
> Is there ANY other use case for waitgroup other than preventing a goroutine
> leak or ensuring that it empties the channels at the end of execution?
I don't think this question is related to the correctness of your
shorter implementation o
With your (imho incorrect) code, the following small modification defers
starting the channel until an add has been called and passes the test:
https://play.golang.org/p/sEFcwcPMdHF
On Sunday, 5 May 2019 11:54:40 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
> > wro
Is there ANY other use case for waitgroup other than preventing a goroutine
leak or ensuring that it empties the channels at the end of execution?
On Sunday, 5 May 2019 11:54:40 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
> > wrote:
>
> > That would mean your cod
On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
wrote:
> That would mean your code, which breaks this code, also breaks the rule about
> never starting a goroutine without having a way to stop it. My code only
> fails when the caller is also failing.
My code does not even contain a go statement
I didn't even think of the condition your code exposes. Partly because at
the same time, if I wrote code that starts goroutines and doesn't have a
section to close them, this deadlock condition created would also be
exposing the fact that the worker pool is not being stopped correctly
either.
The reason your code is shorter is that it is broken. I tried to explain that
to you. Try running the stdlib wait group tests against your code. They will
fail.
> On May 4, 2019, at 4:22 PM, Louki Sumirniy
> wrote:
>
> Those who follow some of my posts here might know that I was discussing t
On Sat, May 4, 2019 at 11:22 PM Louki Sumirniy
wrote:
> The first thing you will notice is that it is a LOT shorter.
It fails a simple test: https://play.golang.org/p/v3OSWxTpTQY The
original is ok: https://play.golang.org/p/OhB8qZl2QLQ
Another problem is starting a new goroutine per Waitgroup.
Those who follow some of my posts here might know that I was discussing the
subject of channels and waitgroups recently, and I wrote a very slim and
simple waitgroup that works purely with a channel.
Note that it is only one channel it requires, at first I had a ready and
done channel, but fou
24 matches
Mail list logo
