RE: [go-nuts] How ignore a subdirectory
You are correct. However, “gofmt .” recurses. It turns out that they handle it differently. John John SouvestreNew Orleans LA, USA504-454-0899 From: golang-nuts@googlegroups.com On Behalf Of Brian Candler Sent: 2023-09-13, Wed 07:30 To: golang-nuts Subject: Re: [go-nuts] How ignore a subdirectory I believe that "go fmt ." (note the space after "go") works on the current package only. On Wednesday, 13 September 2023 at 11:34:35 UTC+1 Jan Mercl wrote: On Wed, Sep 13, 2023 at 12:25 PM John Souvestre mailto:jo...@souvestre.com> > wrote: > I did try that also. I get this error message: > > CreateFile *.go: The filename, directory name, or volume label syntax is > incorrect. Sorry, I'm not familiar with Windows and only TIL cmd.exe does not expand globs. I suggest to install WSL and try something like C:\>bash -c 'gofmt *.go' HTH -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com <mailto:golang-nuts+unsubscr...@googlegroups.com> . To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cf14f4f9-14fa-495e-905e-d7a62d8c070dn%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/cf14f4f9-14fa-495e-905e-d7a62d8c070dn%40googlegroups.com?utm_medium=email_source=footer> . -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/012f01d9e678%2489f2e040%249dd8a0c0%24%40Souvestre.com.
RE: [go-nuts] How ignore a subdirectory
What is TIL? Installing WSL just to solve this seems like it might be overkill. A for loop in a batch file, or in DOSKEY, would suffice. John John SouvestreNew Orleans LA, USA504-454-0899 From: Jan Mercl <0xj...@gmail.com> Sent: 2023-09-13, Wed 05:33 To: John Souvestre Cc: golang-nuts@googlegroups.com Subject: Re: [go-nuts] How ignore a subdirectory On Wed, Sep 13, 2023 at 12:25 PM John Souvestre mailto:j...@souvestre.com> > wrote: > I did try that also. I get this error message: > > CreateFile *.go: The filename, directory name, or volume label syntax is > incorrect. Sorry, I'm not familiar with Windows and only TIL cmd.exe does not expand globs. I suggest to install WSL and try something like C:\>bash -c 'gofmt *.go' HTH -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/012a01d9e678%243ed46070%24bc7d2150%24%40Souvestre.com.
RE: [go-nuts] How ignore a subdirectory
I did try that also. I get this error message: CreateFile *.go: The filename, directory name, or volume label syntax is incorrect. John John SouvestreNew Orleans LA, USA504-454-0899 -Original Message- From: Jan Mercl <0xj...@gmail.com> Sent: 2023-09-13, Wed 01:31 To: John Souvestre Cc: golang-nuts@googlegroups.com Subject: Re: [go-nuts] How ignore a subdirectory On Wed, Sep 13, 2023 at 5:47�AM 'John Souvestre' via golang-nuts wrote: > I�m trying to run gofmt on all of the .go files in a directory, but not any > subdirectories. $ gofmt *.go -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/00f201d9e62c%24a6c5a320%24f450e960%24%40Souvestre.com.
[go-nuts] How ignore a subdirectory
I’m trying to run gofmt on all of the .go files in a directory, but not any subdirectories. I have tried using “.” for the target. It does get all of the .go in the current directory, but it also does all the .go files in subdirectories. To be more specific: There is one particular subdirectory which I don’t want it to process: “_Save”. The https://pkg.go.dev/cmd/go documentation says: Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata". I have used this in the past and it worked fine. But it doesn’t seem to work now. Besides “_Save”, I tried “.Save” and even “testdata”. It processed all of them. The command I am using is “gofmt -d .”. The files in the “_Save” subdirectory are not part of my program’s build, some of them are .go files. There are no references to them in my code, however. Am I misunderstanding something? Or not doing something correctly? I’m doing this on Windows 10, by the way. Thanks, John John SouvestreNew Orleans LA, USA504-454-0899 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/00e601d9e5f5%2404b17ff0%240e147fd0%24%40Souvestre.com.
RE: [go-nuts] question about GO and realtime GC interest by the user community
Hi David. https://en.wikipedia.org/wiki/Real-time_computing#Firm Unfortunately I haven't seen much interest either. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of David Beberman Sent: 2017 November 22, Wed 14:25 To: golang-nuts Subject: Re: [go-nuts] question about GO and realtime GC interest by the user community Hi John, I don't know what firm realtime means. I did look at GO's GC a bit. I'm not the expert in this, others in my company are. On the question of realtime thread priorities, that is a requirement, as is priority inheritance. For hard realtime systems, you want essentially "unfair" scheduling for the realtime threads. Probably significant work, but we do have the advantage of almost 2 decades experience with hard realtime GCs. I'm trying to gauge the market interest in doing this. I haven't seen a lot of response on it. David On Thursday, November 9, 2017 at 2:58:27 PM UTC-5, John Souvestre wrote: I occasionally see projects which have hard real-time requirements, so I’m interested. I understand your concern with GC but you have looked at Go’s current GC? I don’t know if its limits (max pause time, max overhead) are “hard” but they are stated. The one which isn’t is latency due to stopping goroutines since they aren’t exactly pre-emptible. But there’s been some talk about addressing this. I would think that you would need to add priorities and perhaps fairness guarantees to scheduling and synchronization methods. It certainly sounds like a lot of work! Perhaps firm real-time would be a good first step? John John Souvestre - New Orleans LA From: golan...@googlegroups.com [mailto:golan...@googlegroups.com ] On Behalf Of David Beberman Sent: 2017 November 09, Thu 05:59 To: golang-nuts Subject: [go-nuts] question about GO and realtime GC interest by the user community Hi, I asked this on the golang-dev list. They redirected me here. We are a hard realtime JavaVM GC company. By hard realtime we mean that the GC is preemptible, reentrant, non-blocking, non-pausing. For multicore it is also parallel and concurrent. Further for realtime we support priority inheritance for synchronization primitives, and of course hard realtime thread priorities. GO's requirements for GC are slightly different. The concept would be to add our hard RTGC to the GO runtime without disrupting the language. My question is about the interest level in the GO user community. We have developed and marketed hard realtime Java bytecode VM's for 16+ years. GO looks like the new kid on the block. Maybe it moves into realtime use-cases, maybe it doesn't. Kind of doing an extremely informal poll here. Open to any thoughts, comments. Thanks David Beberman Aicas GmbH -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] question about GO and realtime GC interest by the user community
I occasionally see projects which have hard real-time requirements, so I’m interested. I understand your concern with GC but you have looked at Go’s current GC? I don’t know if its limits (max pause time, max overhead) are “hard” but they are stated. The one which isn’t is latency due to stopping goroutines since they aren’t exactly pre-emptible. But there’s been some talk about addressing this. I would think that you would need to add priorities and perhaps fairness guarantees to scheduling and synchronization methods. It certainly sounds like a lot of work! Perhaps firm real-time would be a good first step? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of David Beberman Sent: 2017 November 09, Thu 05:59 To: golang-nuts Subject: [go-nuts] question about GO and realtime GC interest by the user community Hi, I asked this on the golang-dev list. They redirected me here. We are a hard realtime JavaVM GC company. By hard realtime we mean that the GC is preemptible, reentrant, non-blocking, non-pausing. For multicore it is also parallel and concurrent. Further for realtime we support priority inheritance for synchronization primitives, and of course hard realtime thread priorities. GO's requirements for GC are slightly different. The concept would be to add our hard RTGC to the GO runtime without disrupting the language. My question is about the interest level in the GO user community. We have developed and marketed hard realtime Java bytecode VM's for 16+ years. GO looks like the new kid on the block. Maybe it moves into realtime use-cases, maybe it doesn't. Kind of doing an extremely informal poll here. Open to any thoughts, comments. Thanks David Beberman Aicas GmbH -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Converting uint to string
You could also just the integers themselves as keys.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Chun Zhang
Sent: 2017 November 05, Sun 15:09
To: golang-nuts
Subject: [go-nuts] Converting uint to string
Hi, All,
I have a group of integers ranging from 1 to 2^32 that are in the format of
uint32. I know strconv.Itoa(i) or strconv.FormatUint(i) can definitely give
unique representation of each number. So, I can use it as the index of a
map[string]interface{}.
However, I am wondering if I use string(i) only, will I get any two numbers the
same string representation? My guess is no, but would like to get some comments
from you experts.
Also, will string(i) be faster than strconv.Itoa or strcov.FormatUInt?
Thanks,
Chun
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: concurrency programing about go
If you were to do that, yes. I guess it come to: How do you define “done” in
your program? Waitgroup defines it as when all the goroutines which it counted
are closed.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Henrik Johansson
Sent: 2017 November 04, Sat 04:46
To: 2891132l...@gmail.com
Cc: golang-nuts
Subject: Re: [go-nuts] Re: concurrency programing about go
I find continuously adding and calling done on a waitgroup a bit odd. The
waiting goroutine can continue as soon as the count is zero so there is a race
between adds and dones.
On Sat, 4 Nov 2017, 10:01 , <2891132l...@gmail.com> wrote:
Thank you very much.Sorry I still have some question:what's the function of wg?
what does the sentense "wg.Add(2) " mean?? I found that if I change 2 into
1,the result is differnet.
在 2017年11月3日星期五 UTC+8上午4:45:47，snmed写道：
Hi
Here is the code:
Version 1:
package main
import (
"fmt"
"sync"
)
var a string
var once sync.Once
func setup() {
a = "hello,world\n"
}
func doprint() {
once.Do(setup)
fmt.Print(a)
}
func twoprint() <-chan struct{} {
var wg sync.WaitGroup
wg.Add(2)
ch := make(chan struct{})
go func() {
doprint()
wg.Done()
}()
go func() {
doprint()
wg.Done()
}()
go func() {
wg.Wait()
close(ch)
}()
return ch
}
func main() {
ch := twoprint()
<-ch
}
Version 2:
package main
import (
"fmt"
"sync"
)
var a string
var once sync.Once
func setup() {
a = "hello,world\n"
}
func doprint() {
once.Do(setup)
fmt.Print(a)
}
func twoprint() {
var wg sync.WaitGroup
wg.Add(2)
go func() {
doprint()
wg.Done()
}()
go func() {
doprint()
wg.Done()
}()
wg.Wait()
}
func main() {
twoprint()
}
Cheers snmed
Am Donnerstag, 2. November 2017 10:37:15 UTC+1 schrieb 28911...@gmail.com:
Sorry,I try my best to open the website but it can't work.Can you write it
??Thank you so much.
在 2017年10月30日星期一 UTC+8下午4:29:44，snmed写道：
Hi
There are several ways to solve it, here are two of them:
https://play.golang.org/p/wJwkI7HQwv
https://play.golang.org/p/nasUcgBeG4
I prefer the first one, because so I can decide if i want to wait for the end
of twoprint or not.
Cheers
Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com:
Yes, you're right.So how to solve it??
在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：
Hello. I’m guessing that your tried calling twoprint(), but you’ve probably
found that nothing is printed to the screen before your program exits.
Is that correct?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] time.AddDate() odd behavior
> What rule tells us that one month before December 31
is November 30? Or, what rule tells us to normalize November 31 to
November 30 rather than December 1?
End-of-month mode is needed pretty often, in my experience. Perhaps there
should be two rules so the user could choose which fits his situation? The
current method and a new method with a slightly different name, ex: AddEOM?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Alex Dvoretskiy
Sent: 2017 October 31, Tue 16:20
To: golang-nuts
Subject: Re: [go-nuts] time.AddDate() odd behavior
Yes, there is no particular rule for this case. I guess it depends on the
industry, department, or even particular individual. In finance, it would be
normalized to November 30. In power engineering December 1. I'm not proposing.
Just want to know other peoples opinions on this case for better Go
understanding.
On Tuesday, October 31, 2017 at 1:32:47 PM UTC-7, Ian Lance Taylor wrote:
On Tue, Oct 31, 2017 at 10:53 AM, Alex Dvoretskiy
<advore...@gmail.com > wrote:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> t := time.Date(2009, time.December, 31, 23, 0, 0, 0, time.UTC)
> fmt.Println(t)
> fmt.Println(t.AddDate(0, -1, 0))
> }
>
> https://play.golang.org/p/hZ7nhnkepK
>
> The result is
>
> 2009-12-31 23:00:00 + UTC
> 2009-12-01 23:00:00 + UTC
>
>
> I think it should be:
>
> 2009-12-31 23:00:00 + UTC
> 2009-11-30 23:00:00 + UTC
>
>
> Documentation states that "AddDate normalizes its result in the same way
> that Date does, so, for example, adding one month to October 31 yields
> December 1, the normalized form for November 31." This is makes sense when
> you work with time.Date() function, because hours and minutes involved, time
> zones, daylight savings etc.
>
> But it doesn't make any sense If you operate with days, months, years for
> analytical purposes. I think the normal practice ("Normalization") in this
> case would be to add exactly one month just like in other languages. Not one
> month and one day.
I think the function is behaving as documented. You subtracted one
month from December 31, 2009, which gives you November 31, 2009. We
must then normalize that in the same was as the Date function, which
gives you December 1, 2009, which is what you see. I don't think we
can change this now, as it would break backward compatibility. Even
if we were willing to change it, I don't actually understand what you
are proposing. What rule tells us that one month before December 31
is November 30? Or, what rule tells us to normalize November 31 to
November 30 rather than December 1?
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: select is still a little unfair if there are more than 4 cases?
Uniform fairness was my goal, not ordering the selection. A hard real-time
program would require the deterministic latency this would provide.
I agree that any program requiring an ordered selection probably is broken.
Perhaps another method could be used to detect such code.
John
John Souvestre - New Orleans LA
From: Axel Wagner [mailto:axel.wagner...@googlemail.com]
Sent: 2017 October 29, Sun 02:18
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: select is still a little unfair if there are more
than 4 cases?
Apart from practical concerns about how to implement determinism, the
specification of randomness exists for a reason: It prevents programs from
depending on any specific choice for correctness.
(Which is why I asked above what the actual problem is if select isn't
perfectly uniform but just "pretty darn close to. It would seem to me, that a
program depending on uniformity is probably broken)
On Sun, Oct 29, 2017 at 7:38 AM, John Souvestre <j...@souvestre.com> wrote:
Ø So a goroutine has storage for every possible select in the program? If you
do it statically, that's a lot of storage. If you do it dynamically, then you
have a dynamic select -> nextcase map you have to maintain.
Ø You can put that storage on the stack, but just barely: it has to live as
long as the goroutine does, so it has to be at the very top.
Dynamic sounds like the better way. How do you think the run-time overhead
would compare to the current random method?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of keith.rand...@gmail.com
Sent: 2017 October 29, Sun 01:23
To: golang-nuts
Subject: Re: [go-nuts] Re: select is still a little unfair if there are more
than 4 cases?
On Saturday, October 28, 2017 at 11:11:02 PM UTC-7, John Souvestre wrote:
Ø Round robin isn't implementable. There's no place to store the state for an
individual select.
Couldn’t a place be allocated? Since it would be local to a goroutine, put it
on the stack.
Ø I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all goroutines? A
select statement and goroutine pair? A select statement + function instance
pair?
An individual select in a goroutine.
So a goroutine has storage for every possible select in the program? If you do
it statically, that's a lot of storage. If you do it dynamically, then you
have a dynamic select -> nextcase map you have to maintain.
You can put that storage on the stack, but just barely: it has to live as long
as the goroutine does, so it has to be at the very top.
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of
keith@gmail.com
Sent: 2017 October 28, Sat 18:38
To: golang-nuts
Subject: Re: [go-nuts] Re: select is still a little unfair if there are more
than 4 cases?
On Saturday, October 28, 2017 at 2:59:53 PM UTC-7, John Souvestre wrote:
Ø I don't think it needs to be uniformly fair. It just needs to prevent
starvation of a channel for infinity. Any proof would have progress covered if
we pick every channel once in a while, even under a heavily unfair weighting.
You have to balance out the overhead of rolling a fair dice and the speed at
which you can select on channels.
If it were uniformly fair then you couldn’t guarantee picking every channel
once in a while. Statistically it would be become more and more probable, but
never 100%.
Why not just use round-robin? That would guarantee it and it’s a faster
algorithm, I would think. Also, it would sometimes save checking all cases
since you could check them in order, stopping when (if) you found one ready.
Are there situations where it is better for it to be random or is there some
implementation advantage (not having to save state for the select)?
Round robin isn't implementable. There's no place to store the state for an
individual select. And you can't store the state in the G (goroutine) or M (os
thread) because then:
for {
select {
case <-x:
case <-y:
}
select {
case <-y:
case <-x:
}
}
would never read from y (or x, depending on the initial state).
I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all goroutines? A
select statement and goroutine pair? A select statement + function instance
pair?
(The last one is actually implementable - but then select statements behave
differently if you wrap them in a function.)
John
John Souvestre - New Orleans LA
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
RE: [go-nuts] Re: select is still a little unfair if there are more than 4 cases?
Ø So a goroutine has storage for every possible select in the program? If you
do it statically, that's a lot of storage. If you do it dynamically, then you
have a dynamic select -> nextcase map you have to maintain.
Ø You can put that storage on the stack, but just barely: it has to live as
long as the goroutine does, so it has to be at the very top.
Dynamic sounds like the better way. How do you think the run-time overhead
would compare to the current random method?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of keith.rand...@gmail.com
Sent: 2017 October 29, Sun 01:23
To: golang-nuts
Subject: Re: [go-nuts] Re: select is still a little unfair if there are more
than 4 cases?
On Saturday, October 28, 2017 at 11:11:02 PM UTC-7, John Souvestre wrote:
Ø Round robin isn't implementable. There's no place to store the state for an
individual select.
Couldn’t a place be allocated? Since it would be local to a goroutine, put it
on the stack.
Ø I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all goroutines? A
select statement and goroutine pair? A select statement + function instance
pair?
An individual select in a goroutine.
So a goroutine has storage for every possible select in the program? If you do
it statically, that's a lot of storage. If you do it dynamically, then you
have a dynamic select -> nextcase map you have to maintain.
You can put that storage on the stack, but just barely: it has to live as long
as the goroutine does, so it has to be at the very top.
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
keith@gmail.com
Sent: 2017 October 28, Sat 18:38
To: golang-nuts
Subject: Re: [go-nuts] Re: select is still a little unfair if there are more
than 4 cases?
On Saturday, October 28, 2017 at 2:59:53 PM UTC-7, John Souvestre wrote:
Ø I don't think it needs to be uniformly fair. It just needs to prevent
starvation of a channel for infinity. Any proof would have progress covered if
we pick every channel once in a while, even under a heavily unfair weighting.
You have to balance out the overhead of rolling a fair dice and the speed at
which you can select on channels.
If it were uniformly fair then you couldn’t guarantee picking every channel
once in a while. Statistically it would be become more and more probable, but
never 100%.
Why not just use round-robin? That would guarantee it and it’s a faster
algorithm, I would think. Also, it would sometimes save checking all cases
since you could check them in order, stopping when (if) you found one ready.
Are there situations where it is better for it to be random or is there some
implementation advantage (not having to save state for the select)?
Round robin isn't implementable. There's no place to store the state for an
individual select. And you can't store the state in the G (goroutine) or M (os
thread) because then:
for {
select {
case <-x:
case <-y:
}
select {
case <-y:
case <-x:
}
}
would never read from y (or x, depending on the initial state).
I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all goroutines? A
select statement and goroutine pair? A select statement + function instance
pair?
(The last one is actually implementable - but then select statements behave
differently if you wrap them in a function.)
John
John Souvestre - New Orleans LA
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: select is still a little unfair if there are more than 4 cases?
Ø Round robin isn't implementable. There's no place to store the state for an
individual select.
Couldn’t a place be allocated? Since it would be local to a goroutine, put it
on the stack.
Ø I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all goroutines? A
select statement and goroutine pair? A select statement + function instance
pair?
An individual select in a goroutine.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of keith.rand...@gmail.com
Sent: 2017 October 28, Sat 18:38
To: golang-nuts
Subject: Re: [go-nuts] Re: select is still a little unfair if there are more
than 4 cases?
On Saturday, October 28, 2017 at 2:59:53 PM UTC-7, John Souvestre wrote:
Ø I don't think it needs to be uniformly fair. It just needs to prevent
starvation of a channel for infinity. Any proof would have progress covered if
we pick every channel once in a while, even under a heavily unfair weighting.
You have to balance out the overhead of rolling a fair dice and the speed at
which you can select on channels.
If it were uniformly fair then you couldn’t guarantee picking every channel
once in a while. Statistically it would be become more and more probable, but
never 100%.
Why not just use round-robin? That would guarantee it and it’s a faster
algorithm, I would think. Also, it would sometimes save checking all cases
since you could check them in order, stopping when (if) you found one ready.
Are there situations where it is better for it to be random or is there some
implementation advantage (not having to save state for the select)?
Round robin isn't implementable. There's no place to store the state for an
individual select. And you can't store the state in the G (goroutine) or M (os
thread) because then:
for {
select {
case <-x:
case <-y:
}
select {
case <-y:
case <-x:
}
}
would never read from y (or x, depending on the initial state).
I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all goroutines? A
select statement and goroutine pair? A select statement + function instance
pair?
(The last one is actually implementable - but then select statements behave
differently if you wrap them in a function.)
John
John Souvestre - New Orleans LA
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: select is still a little unfair if there are more than 4 cases?
Ø I don't think it needs to be uniformly fair. It just needs to prevent starvation of a channel for infinity. Any proof would have progress covered if we pick every channel once in a while, even under a heavily unfair weighting. You have to balance out the overhead of rolling a fair dice and the speed at which you can select on channels. If it were uniformly fair then you couldn’t guarantee picking every channel once in a while. Statistically it would be become more and more probable, but never 100%. Why not just use round-robin? That would guarantee it and it’s a faster algorithm, I would think. Also, it would sometimes save checking all cases since you could check them in order, stopping when (if) you found one ready. Are there situations where it is better for it to be random or is there some implementation advantage (not having to save state for the select)? John John Souvestre - New Orleans LA -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] will the following code always print two 1?
Hi Dave. Oops! I read it as "pad". My bad. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 October 22, Sun 22:27 To: golang-nuts Subject: Re: [go-nuts] will the following code always print two 1? Thanks Keith. I fat fingered my response and it probably wasn’t clear that I was talking about the requirement to pair atomic stores and loads. I agree that if atomic store and loads are used for both variables, the program will print a 1 On Monday, 23 October 2017 14:01:17 UTC+11, John Souvestre wrote: Interesting. I hadn't heard this. Do you happen to recall where you ran across it? Ref: https://go-review.googlesource.com/c/go/+/65210 Also: <https://github.com/golang/go/issues/5045> https://github.com/golang/go/issues/5045 I did a fast (not comprehensive) look at about 10 files in Go\src\... in which I found "atomic.StoreUint". None of them seemed to use any padding. Not sure where you're going with this, I tried to write `pair atomic` in my previous message but it came out as `paid atomic`, sorry for the confusion. John John Souvestre - New Orleans LA -Original Message- From: golan...@googlegroups.com [mailto:golan...@googlegroups.com ] On Behalf Of Dave Cheney Sent: 2017 October 22, Sun 17:07 To: golang-nuts Subject: RE: [go-nuts] will the following code always print two 1? If that we�re the case then you wouldn�t need to paid an atomic.Store with an atomic.Load. But as I understand it, you do. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] will the following code always print two 1?
Summarizing various conversations I've seen: The Go Memory Model says that "synchronization primitives" are in the sync and sync/atomic packages. It also says that a "synchronization mechanism" establishes relative ordering as observed by another goroutine. In other words, Go's atomics are full memory barriers/fences which guarantee sequential consistency for any number of goroutines. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 October 22, Sun 15:22 To: golang-nuts Subject: Re: [go-nuts] will the following code always print two 1? Nope, as I understand it atomic load and store are not memory fencing operations. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Latest Tiobe Ranking
You could mention to your colleagues that if they scroll down on the Tiobe page they will find Go listed in their Hall of Fame as the "Programming Language of the Year" for 2009 and 2016. I second Ian's recommendation of Redmonk and IEEE - if you must reference any such lists. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of snmed Sent: 2017 October 09, Mon 13:14 To: golang-nuts Subject: Re: [go-nuts] Latest Tiobe Ranking Hi Ian Thank you for your elaboration. I won't choose a language because of such index, but I'm trying to convince my colleagues of the benefits of go and therefore no matter how funny such indexes are, it isn't useful as well. I'm always looking for success stories about using go from other companies. Cheers -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Are all running goroutines killed when main ends?
Any easy way to make their defers run? John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 October 05, Thu 23:36 To: golang-nuts Subject: [go-nuts] Are all running goroutines killed when main ends? Yes, they will be stopped. However they will be stopped abruptly, no defers will run. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Memory Safety
Thanks for the info. I believe that Windows generally requires that user opt-in (set in the exe) for DEP and ASLR. However, it seems that Go exe's for Windows don't have the DEP opt-in set. Worth opening some issues? John John Souvestre - New Orleans LA -Original Message- From: Ian Lance Taylor [mailto:i...@golang.org] Sent: 2017 October 04, Wed 15:27 To: John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] Memory Safety On Wed, Oct 4, 2017 at 1:07 PM, John Souvestre <j...@souvestre.com> wrote: > > Does Go provide Data Execution Prevention (DEP) and Address space layout > randomization (ASLR)? Go does not prevent the operating system from implementing Data Execution Prevention. If the OS implements it, it will apply to Go programs as it does to programs written in any other language. Go supports ASLR on GNU/Linux systems by passing -buildmode=pie to `go build` or `go install`. -buildmode=pie is currently supported on GNU/Linux and Android systems. Since the 1.9 release support was added for Darwin amd64. It should be straightforward to add support for other Unix systems, if anybody wants to do that. I don't know what would be involved in adding support for Windows. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Memory Safety
Does Go provide Data Execution Prevention (DEP) and Address space layout randomization (ASLR)? If not, any reasons why or any plans to implement? Thanks, John John Souvestre - New Orleans LA -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Running Go binary on a 56 core VM
There are lots of variables, but even with a directly connected SSD drive (SATA bus, in my case) I can pretty well top out the file i/o, just doing sequential file reads, with about 3 – 4 CPUs. So increasing GOMAXPROCS (in this case) doesn’t help. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Linker Sent: 2017 September 04, Mon 00:50 To: r...@google.com Cc: golang-nuts Subject: Re: [go-nuts] Re: Running Go binary on a 56 core VM More File-IO, more GOMAXPROCS. On Mon, Sep 4, 2017 at 3:44 AM, rlh via golang-nuts <golang-nuts@googlegroups.com> wrote: Without building and measuring it is impossible to know which of these approaches, or even a third one where you simply run a single instance, is best for your application. Each approach has upsides and downsides. The GC believes GOMAXPROCS and will uses as much CPU as it believes is available. This can take CPU away from the other 3 instances. If more CPU is available but the GC doesn't know about it then those cycles will go unused. Build, measure, and figure out why the application is seeing different performance characteristics. Please report back, 56 HW threads and 256Gbytes RAM is of considerable interest to many of us. On Thursday, August 31, 2017 at 9:59:59 AM UTC-4, Pradeep Singh wrote: Hi Guys, So, we wrote a Go service which does some heavy network IO over ZMQ (using cgo calls). Now, we have to put this service on a VM in private cloud which has 56 cores and 256GB of physical memory. I am guessing it is mostly a dual core NUMA Intel Xeon machine with Xen installed on it. We want to horizontally scale the application by launching 4 instances of this service in this VM. We have tested the code for 30K+ QPS on a 16 core EC2 AMI. There are two ways we can do it. 1. Run 4 instances of the application as it is without changing any defaults except configuration files and output data folders. 2. Run 4 instances of the application after modifying GOMAXPROCS. - GOMAXPROCS=16 ./run-my-unoptimized-app Which of these 2 scenarios would benefits us more in terms of performance. Does it makes sense to run all with default GOMAXPROCS value, which would be 56 for all the 4 instances? Or it would be wise to follow option 2 with possibly pinning each to a range of 16 cores using taskset. Would pinning help in second scenario? Thanks, -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Regards, Linker Lin linker.m@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] golang gc stop the world how to stop cpu busy goroutine?
Although a goroutine isn’t pre-emptible by the Go scheduler, there is an opportunity whenever it does something which blocks or when it calls a non-inlined function. So generally the GC’s STW can take place pretty quickly. But if you are doing something with is totally compute bound then it can be a problem. An easy solution is to insert a call to runtime.Gosched() every so often. I believe that there is an ongoing discussion about a way for Go to plan ahead and be able to handle even these cases, but it’s something for the future. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of ??? Sent: 2017 September 04, Mon 00:47 To: golang-nuts Subject: [go-nuts] golang gc stop the world how to stop cpu busy goroutine? when have one or two cpu busy goroutine in my server (example for loop empty), the gc stop the world how to stop the goroutine ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Go channels overused and hyped?
Interesting. So you think it is a general safety advisory (which would apply to any language) to use synchronization (ex: mutex or channel) and not a more focused push to use channels? Hmmm... I didn't understand it that way. I thought that "communicate" was a reference to the "C" in CSP. It never crossed my mind that it would mean "use synchronization". The context of the Go FAQ section which includes the proverb discourages mutexes (with no mention of when they should or should not be used). The two links it provides bolster this and only provide examples using channels. The wiki article MutexOrChannel starts off with the proverb then immediately follows with "That said, Go does provide traditional locking mechanisms in the sync package." Why the need to say this if the moto was meant to include the sync methods, too? Everything I recall reading or listening to which references the proverb seems to continue in this theme to avoid locking. Here's a rather explicit one from https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions: " Don’t communicate by sharing memory, share memory by communicating. Our first proverb–don’t mediate access to shared memory with locks and mutexes, instead share that memory by communicating." Also, in Rob Pike's talk "Go Proverbs" at Gopherfest on 11/18/2015 he talks about this proverb. He defines "sharing memory by communicating" as "passing on a channel the address of a data structure or an object ...". So I don't think that I'm alone in thinking that the focus of the proverb is to use channels to share memory, rather than any other way. And I find this somewhat wrong and certainly confusing. Am I really alone in this? John John Souvestre - New Orleans LA -Original Message- From: Ian Lance Taylor [mailto:i...@golang.org] Sent: 2017 August 18, Fri 15:14 To: John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] Go channels overused and hyped? On Fri, Aug 18, 2017 at 12:02 PM, John Souvestre <j...@souvestre.com> wrote: > > I think that both of the suggestions below are great. But I�m left > wondering about the Go mantra > > > > Do not communicate by sharing memory. Instead, share memory by > communicating. > > > > What does it say? It starts off with communicating as the goal, but doesn�t > tell you how to do it. Then sharing memory is the goal and the solution it > provides (communicating) is only right some of the time. > > > > Am I missing something? Should this be replaced? As I see it, the point of the proverb is to focus on having goroutines use explicit communication mechanisms, such as channels and mutexes, to hand control of an area of memory over to another goroutine. An example of communicating by sharing memory would having one goroutine poll a memory location that is then changed by a different goroutine. As a general guideline, prefer explicit communication mechanisms. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Go channels overused and hyped?
P.S. And if you want to reduce it to a one-liner, how about this? Communicating is better than sharing sometimes, and vice versa. John John Souvestre - New Orleans LA From: John Souvestre [mailto:j...@souvestre.com] Sent: 2017 August 18, Fri 14:03 To: 'golang-nuts' Subject: RE: [go-nuts] Go channels overused and hyped? I think that both of the suggestions below are great. But I’m left wondering about the Go mantra Do not communicate by sharing memory. Instead, share memory by communicating. What does it say? It starts off with communicating as the goal, but doesn’t tell you how to do it. Then sharing memory is the goal and the solution it provides (communicating) is only right some of the time. Am I missing something? Should this be replaced? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Michael Jones Sent: 2017 August 18, Fri 08:57 To: Tamás Gulácsi Cc: golang-nuts Subject: Re: [go-nuts] Go channels overused and hyped? yes... everything is good for what it is designed for and less-good for what it is not designed for. mutex-protected counters are good channels for data communication are good neither is a perfect stand in for the other. nothin wrong with channels. On Fri, Aug 18, 2017 at 4:38 AM, Tamás Gulácsi <tgulacs...@gmail.com> wrote: No. Use channels to coordinate and send data between goroutines, and other sync primitives to coordinate access to shared resources. Both has its pros and cons, use the best tool for the job. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com <mailto:golang-nuts%2bunsubscr...@googlegroups.com> . For more options, visit https://groups.google.com/d/optout. -- Michael T. Jones michael.jo...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] multiply and divide
Ø "multiply first, then divide." While often the right method, I don’t think that it always is. Consider: -Integer: It is as long as the product doesn’t overflow (before the divide). -Floating: I’m inclined to think that combining numbers of the same magnitude first might be a better approach. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Michael Jones Sent: 2017 August 18, Fri 11:50 To: golang-nuts Subject: [go-nuts] multiply and divide Here is a minor musing from something that came up yesterday. Sometimes we see a real number expression as simple as... x*y/z ...and knowing from basic algebra that... (x*y)/z == x*(y/z) ...we might not expect much difference between the two in our code. Alas, computer floating point does not involve real numbers, rather it uses an approximation of them. If you will copy https://play.golang.org/p/IlDxtvx7IY to your computer, build and run it, (too much CPU for the playground) you'll find that the order makes a difference. Or, you can just remember this phrase, "multiply first, then divide." -- Michael T. Jones michael.jo...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is this bad concurrency?
You might want to consider using a sync.WaitGroup. It’s for such situations.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of bill.war...@talentinc.com
Sent: 2017 August 18, Fri 13:01
To: golang-nuts
Subject: [go-nuts] Is this bad concurrency?
Hi,
https://play.golang.org/p/lR6_mxSjtb
I have two long running things to do, I'd like to do them in parallel, then
sync up at the end. I've written it as a function which gets one thing done,
and which backgrounds the second thing with a goroutine. Thing one has a lot of
reasons to exit early, and I need to signal those to thing two so that the go
routine can exit cleanly and not create a goroutine leak. Standard fare,
usually solved by introducing a channel and a select statement. I want to
signal done for early exits, including panics, so I thought I would write to
the done channel in a defer block. That caused a problem, because in the happy
case, both the foreground and the background routines are finished, the done
channel has no reader, so writing to it in the defer block causes "fatal error:
all goroutines are asleep - deadlock!" So I introduced a new boolean variable
("clean_finish") that is false until the background job completes, and which is
tested in the defer block before writing to the done channel. Is there anything
wrong with my approach? You can see the code in the playground link above, or
down below.
package main
import (
"sync/atomic"
"fmt"
"time"
)
func main() {
ch := make(chan int)
done := make(chan struct{})
var clean_finish uint32
defer func() {
fin := atomic.LoadUint32(_finish)
if fin != 1 {
done <- struct{}{}
}
}()
go func() {
defer func() {
fmt.Println("we're done here")
}()
select {
case <-time.After(time.Second * 1):
ch <- 1
atomic.StoreUint32(_finish, 1)
case <- done:
fmt.Println("early exit")
}
}()
panic("bye") // comment this out to see normal behavior
n := <- ch
fmt.Printf("n: %v\n", n)
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Goroutines chan to get data at specific time
I’m not sure exactly what you are trying to accomplish, but I suspect that this
article would help you.
https://blog.golang.org/go-concurrency-patterns-timing-out-and
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 August 06, Sun 09:58
To: golang-nuts
Subject: [go-nuts] Re: Goroutines chan to get data at specific time
yes this is what I want..
Need to access web service multiple times to get the entire data unless return
status is not "completed" But same time I need timeout
Thanks for the help
Thanks
Abhi
On Sunday, August 6, 2017 at 7:48:05 PM UTC+5:30, snmed wrote:
I still no get the idea behind your requirement, in your example you calling
the web service 6 times in sequential manner and then write it to the channel.
But again you can only write once to a channel with a capacity of one, as long
as you not read from the same channel and you still read it in the select
statement.
That means all other calls to 'GetPartWebServiceData()' in the goroutine are
blocked until that read in the select statement happens. In your case it is
always the first
value written to the channel.
I try to give you a solution with although i'm not completely understand your
requirements:
Here a working sequential solution: https://play.golang.org/p/2qohwIjP96
I hope that helps
Cheers snmed
Am Sonntag, 6. August 2017 13:05:11 UTC+2 schrieb Abhijit Desai:
Requirement is to collect the data with in cuttoff time say 3 sec by invoking
web service multiple times and return only latest invoked data
c1 <- "result 1" // In real scenario this taking almost 1 seconds as in real
scenario it's taking Part chunk of data from Web Service
Something like... Expecting data from c1 <- GetPartWebServiceData("request 3")
//at least I should get this data!?
package main
import "time"
import "fmt"
func main() {
c1 := make(chan string, 1)
go func() {
c1 <- GetPartWebServiceData("request 1") //say try 6 times
c1 <- GetPartWebServiceData("request 2")
c1 <- GetPartWebServiceData("request 3") //at least I should get this
data!?
c1 <- GetPartWebServiceData("request 4")
c1 <- GetPartWebServiceData("request 5")
c1 <- GetPartWebServiceData("request 6")
}()
select {
case res := <-c1: //here program get out without waiting 3 seconds
because it got the data
fmt.Println(res)
case <-time.After(time.Second * 4):
fmt.Println("timeout")
}
}
func GetPartWebServiceData(request string) string{
time.Sleep(time.Second * 1) // Time Consuming work returning part value
partResponse := "Response for " + request //some response
return partResponse
}
On Sunday, August 6, 2017 at 4:03:08 PM UTC+5:30, snmed wrote:
Hi
What are you trying to solve? Your channel has a capacity of 1, the first write
to c1 is successful but the second write to c1 is blocked until it has been
read in the select statement. And therefore you print the first value written
to c1.
I recommend you to read this https://golang.org/doc/effective_go.html#channels
documentation about channels.
Cheers snmed
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: No Allman-Style, No go!
Cognitive dissonance J
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Michael Jones
Sent: 2017 July 27, Thu 15:38
To: Rob Pike
Cc: Ecstatic Coder; golang-nuts
Subject: Re: [go-nuts] Re: No Allman-Style, No go!
Ecstatic, based on what you said here ("some people will never be forced to
change" and "because Google engineers have decided"), I believe there are a few
ideas you may profitably consider about the formatting topic--ideas that you
probably have not yet considered and which may ease your concerns.
FIRSTLY, there are probably people who would absolutely refuse to visit the
United Kingdom because "they will never be forced to drive on the wrong side of
the road." Or perhaps, they would visit, but would drive on "the right side
show those silly UK people see how we do it at home." Some, but not many,
because most people understand that being in a society of people who drive on
one side of the road is best embraced by sharing that same side. This has
nothing to do with anyone's opinion about which side is truly and naturally the
best and wisest side to drive on. It is instead about driving effectively as an
ensemble rather than alone as an isolated individual.
As surprising as it may be, this is a very similar to the situation with the
style gofmt implements (which side of the road) and the reason that whatever
style it is is considered important by other developers (the other drivers).
Now, this is all in the context of more than one developer (one car/one
driver). If you build a private road at your estate than you're surely welcome
to drive on either side, down the middle, or even to weave back and forth in a
sinusoidal pattern. Whatever makes you happy. Whatever you see as the "one true
way." The idea of fitting in for the purpose of mutual survival or efficiency
is not at play when you are alone.
Maybe you program alone. Maybe nobody else sees your code. Maybe you do not
wish to import and examine the code of others nor export code of your own. If
so, this entire thread is not really meant for you. However...
SECONDARIALY, one of the most important aspects of being a Google [software]
engineer is the reality of working in a multi-hundred million line source code,
with 10,000+ other programmers, and having every line of code reviewed by other
developers before checkin. (Important, but not unique--same at IBM, Oracle,
Microsoft, Apple, ...) In this kind of professional team development
environment, the efficiency of code reuse, of quickly understanding the code of
others, and of avoiding false source code deltas based in stylistic changes is
paramount. Google started in a garage, but did not stay there. This attention
to working as a team, grew with the company as it does in other large,
effective software teams.
To the extent that a "common style has been forced because Google engineers
decided," it is actually the case that "Google engineers were forced by scale
to accept a common format." Not that they are victims, just that like drivers
and modern society, they grew weary of needless traffic jams, accidents, and
injuries. I've travelled very long distances in India, for example, where there
are often no lane markers on roads and people drive on whatever part they like.
With such kind people it works well in the country, but in the cities where
congestion reaches a critical mass, it seems to work spectacularly poorly.
The rigidity that frustrates you is the price of society, of easy code review
and understanding; it is not, as some presume, a declaration of a "best" way to
indent. Rather it is an example of a "best way to collaborate at scale" which
is just the kind of situation where Go intends to solve existing problems.
My views, not Google's.
On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike <r...@golang.org> wrote:
Very few, though. Very few.
As the proverb says:
<https://www.youtube.com/watch?v=PAAkCSZUG1c=8m43s> Gofmt's style is no
one's favorite, yet gofmt is everyone's favorite.
-rob
On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder <ecstatic.co...@gmail.com>
wrote:
Btw please don't take it personally. What I'm saying is that indeed some people
(including me as you see) WILL NEVER agree to be forced to change their coding
style because Google engineers have decided so, but that doesn't mean we should
stay away from go just because of our mental incapacity to agree on that.
On Thu, Jul 27, 2017 at 9:32 AM, <ecstatic.co...@gmail.com> wrote:
I don't know if you have read this post above :
"BTW, I've just released Genesis, an open source generic preprocessor which
automatically converts Allman style code into K and allows genericity by
parametric instantiation.
https://gith
RE: [go-nuts] Re: No Allman-Style, No go!
Ø Btw here are the result of a small internet poll on indentation styles : - Allman : 7450 votes - K style : 5514 votes Ø … I have to wonder if a person’s choice of style might depend on which language they are using. For example, I might prefer Allman while working in C but K while working in Go. The deciding factor being that Go always uses a block for if’s, while C (if memory serves) uses either a single statement or a block. Thus, when scanning the code quickly, seeing the opening brace doesn’t add any info to my understanding of what takes place in Go while it would in C. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of ecstatic.co...@gmail.com Sent: 2017 July 27, Thu 03:33 To: golang-nuts Cc: yout...@z505.com Subject: Re: [go-nuts] Re: No Allman-Style, No go! I don't know if you have read this post above : "BTW, I've just released Genesis, an open source generic preprocessor which automatically converts Allman style code into K and allows genericity by parametric instantiation. https://github.com/senselogic/GENESIS Better late than never... ;)" Obviously, I don't like AT ALL the K style, to which I prefer the Allman style, for not only personal but also OBJECTIVE reasons. And yet I've learned Go and enjoy a lot to use this language, despite this implies using an external tool to add genericity and fix the code indentation. Btw here are the result of a small internet poll on indentation styles : - Allman : 7450 votes - K style : 5514 votes - Whitesmith : 455 - GNU : 422 - Horstman : 131 - Pico : 93 - Banner : 243 (http://www.terminally-incoherent.com/blog/2009/04/10/the-only-correct-indent-style) Even if these 14000 votes are obviously not enough to reflect the whole development community, at least you can see here that many developers prefer the Allman style to the K style. So sorry, but I completely disagree with your advice to stay away from Go if you don't like its forced indentation style policy. It's not only too radical, but also not needed, as there are already tools to fix that issue. On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote: I propose a new rule for our Code of Conduct: Before posting to the "No Allman-Style, No go!" thread, you shall read and understand all previous posts in the aforementioned thread. Justo to be clear: Go indentation style is a time saver. It was carefuly crafted to piss some people off. As you can see, it works wonders. If someone can't handle a simple change in indentation style, then she has no business trying to learn Go, so she quits, thus saving time. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Understanding least significant byte operation
Hi Jan. Hmmm… Here’s what I see. 0001 0001 0010 0010 0011 0001 0100 0100 0101 0001 … 1100 0100 1101 0001 1110 0010 0001 That looks like the least significant set bit to me. John John Souvestre - New Orleans LA From: Jan Mercl [mailto:0xj...@gmail.com] Sent: 2017 July 23, Sun 13:52 To: John Souvestre; golang-nuts@googlegroups.com Subject: Re: [go-nuts] Understanding least significant byte operation On Sun, Jul 23, 2017 at 7:26 PM John Souvestre <j...@souvestre.com> wrote: > I believe that the result is the least significant bit, not byte. Does not look like that: https://play.golang.org/p/thzUaazLSp -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Understanding least significant byte operation
I believe that the result is the least significant bit, not byte.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Pablo Rozas Larraondo
Sent: 2017 July 23, Sun 07:51
To: golang-nuts
Subject: [go-nuts] Understanding least significant byte operation
I have seen Go code using this function to find out the least significant byte
of unsigned integers:
func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
This function works fine but I wonder why, if call the same AND operation, it
results in an error: "constant -X overflows uint64"
Here is a playground example to illustrate this:
https://play.golang.org/p/_0EYtlLnmG
Does anyone know what changes when -uint64() is called in a return statement?
How a negative uint should be interpreted?
Thank you,
Pablo
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] does Go memory model guarantee this program always prints 1?
Hi Marvin.
> Yes, assuming the Go authors agree that atomic operations guarantee
> non-concurrency. Can we have someone authoritative weigh in here?
The Memory Model says that "synchronization primitives" are in the sync and
sync/atomic packages. It also says that a "synchronization mechanism"
establishes relative ordering as observed by another goroutine. In other
words, Go's atomics are full memory barriers/fences which guarantee sequential
consistency for any number of goroutines.
I'm not an authority, but I believe that both Rob and Ian confirm this in
https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ
John
John Souvestre - New Orleans LA
-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Marvin Renich
Sent: 2017 July 10, Mon 12:09
To: golang-nuts
Subject: Re: [go-nuts] does Go memory model guarantee this program always
prints 1?
[Reply-To set; I don't need two copies of replies.]
* T L <tapir@gmail.com> [170710 12:31]:
> so this is guaranteed by Go memory model?
>
> package main
>
> import "fmt"
> import "sync/atomic"
>
> func main() {
> var x, y int32
> go func() {
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
> }()
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is
> printed?
> }
> }
Asked and answered in your previous msg. Yes, assuming the Go authors
agree that atomic operations guarantee non-concurrency. Can we have
someone authoritative weigh in here?
...Marvin
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Writing a non-blocking thread-safe buffer
A few ideas… Instead of using two channels, use just one. Let the writer(s) use a “select” to do the write, else default to doing a read (then loop to try the write again). I believe that would accomplish what you are doing now but with less overhead. I think that it’s great that you implemented this with channels first. If you need more throughput then I’d think mutexes next, and atomics as a last resort. Perhaps using an array as a circular buffer with read and write accesses synchronized by mutexes would be a good next step. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Eno Compton Sent: 2017 April 06, Thu 23:29 To: golang-nuts Subject: [go-nuts] Writing a non-blocking thread-safe buffer Hi All, I'm trying to write a non-blocking thread-safe buffer for use in a high throughput system. In short, I want to create a buffer that decouples the speed of writes from that of reads. For a first attempt, using channels in the implementation seems best. Here is a link <https://play.golang.org/p/d01uanEjbN> to the current implementation. I have a write channel and a buffered read channel. As an intermediary between the two channels, I spin off a goroutine on initialization of the buffer which constantly pulls values off the write channel and attempts to put them on to the read channel. If the read channel is full, I discard a value from the read channel before inserting the new value. This implementation works. What I seek to do now is improve the throughput of the buffer. I understand doing so requires proper benchmarking and measuring. What I'm curious about though is the experience of others on this list. In systems which require high throughput, am I best suited sticking with channels? Would atomics be an appropriate design choice? What about mutexes? Forgive me if this question seems naive. I'm new to Go and am still developing a sense for the language. Thanks, Eno -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client?
Ni Nick. Is 1GB too much? What is your target for number of connections and max memory size? You are using about 100KB per connection? Is there any way to reduce this? The goroutine certainly isn’t much of that. Perhaps some way of using a smaller buffer while idling? Go does use epoll, but not sharing the memory. It sounds like it might be a nice option for the future, however. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Nick Rio Sent: 2017 March 06, Mon 02:26 To: golang-nuts Subject: Re: [go-nuts] Re: How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client? Hi John, The application is working right now. Current work for me is to found a way to reduce it's memory footprint as it will take at least 1GB memory to hold only C10K idle connections. I know it's mainly me causing such memory usage, so I just want to know if there are a better way to get around my problem without changing too many of those already existing design. That's is when the epoll-style idea came out. + epoll-styled design is seems suits better for my application by nature. I really hope Golang can have it built in though. On Monday, March 6, 2017 at 3:54:19 PM UTC+8, John Souvestre wrote: What you propose sounds like a lot of extra work at the onset. Consider starting with a simple trial version of your program would get you up and running with less effort. This way you could see whether CPU or memory is the limiting factor, and could work to optimize just that factor (and not waste time on the wrong factor). Or perhaps the trial version will achieve your goals without having to do any optimization. J John John Souvestre - New Orleans LA From: golan...@googlegroups.com [mailto:golan...@googlegroups.com ] On Behalf Of Nick Rio Sent: 2017 March 05, Sun 23:28 To: golang-nuts Subject: [go-nuts] Re: How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client? Thank you for reply. No guys, it's me using too many memories, not Goroutine. However, I believe if I can make those code in epoll-style, I can then build a task queue to handle those connections one by one in a queue when they back to active. For example, start one *accepter* goroutine + few *worker* goroutines. Then I could do buffer sharing within each *worker* instead of each connections. Which well reduce a huge bunch of memory requirement + also reduce numbers of goroutine. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: [Newbie] Why this code is so slow?
Changing just the mod operation to int32 made the whole program run about 2.5 times faster for me. Wow! I had no idea that there would be that much difference. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Konstantin Shaposhnikov Sent: 2017 February 26, Sun 00:42 To: golang-nuts Subject: [go-nuts] Re: [Newbie] Why this code is so slow? int type in Go is 64 bit on 64 bit system . Most likely you are using 32 bit integers in other languages (e.g. int in Java). 64 bit division is slower than 32 bit. Try changing your Go program to use int32 instead and see if it becomes faster. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Debugging long GC pauses
Or… Call runtime.Gosched(). I seem to recall benchmarking it a while back and found that it was very efficient. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Jesper Louis Andersen Sent: 2017 February 23, Thu 16:18 To: Austin Clements; Oliver Beattie Cc: golang-nuts Subject: Re: [go-nuts] Debugging long GC pauses What would happen if you inserted a dummy function call inside the non-preemptible loop and made an appropriate sacrifice on the altar of the SSA dead-code-eliminator so it doesn't trigger? On Thu, Feb 23, 2017 at 8:46 PM 'Austin Clements' via golang-nuts <golang-nuts@googlegroups.com> wrote: AFAIK, the only thing that can cause this in Go 1.8 is a non-preemptible loop. It's not related to the heap size at all. To test this theory, you can set GOEXPERIMENT=preemptibleloops and rebuild your Go tree (the compiler has to be built with this, so you can't just turn it on to build your project). I wouldn't recommend running in production with this, but if it eliminates the long pauses, we'll at least know that's the culprit. Since these are quite long, the other thing you can do is run with the execution tracer (https://godoc.org/runtime/trace). You'll be able to see exactly what's happening at the beginning of each GC cycle. If you do have non-preemptible loops, you should also see goroutines executing for much longer than 10ms at a time, which is the default preemption bound. On Thu, Feb 23, 2017 at 1:46 PM, Oliver Beattie <oli...@obeattie.com> wrote: I am looking for some advice about how I can debug some long GC pauses I am observing in our production workloads under go 1.8 (the problem is not specific to 1.8, though). This is a very simple network server – basically a HTTP ping endpoint – but I regularly see tail request latencies of >100ms. I have enabled GODEBUG=gctrace=1, and I can see some quite long STW pauses amid lots of much less worrying pauses: gc 54 @348.007s 0%: 0.061+81+0.040 ms clock, 0.12+0.39/81/81+0.081 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 55 @358.007s 0%: 0.21+83+0.019 ms clock, 0.43+80/2.7/81+0.039 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 56 @367.507s 0%: 80+1.3+0.065 ms clock, 161+0.080/1.2/82+0.13 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 57 @377.726s 0%: 0.054+63+0.023 ms clock, 0.10+0.68/61/0.44+0.046 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 58 @388.007s 0%: 0.033+81+0.036 ms clock, 0.067+0.32/80/81+0.072 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 59 @398.007s 0%: 0.021+82+0.019 ms clock, 0.043+0.17/80/82+0.038 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 60 @407.630s 0%: 0.012+57+0.031 ms clock, 0.025+0.25/0.64/57+0.063 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 61 @418.007s 0%: 0.19+1.0+79 ms clock, 0.38+0.28/0.69/0.98+159 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 62 @427.507s 0%: 0.21+81+0.29 ms clock, 0.42+81/0.96/81+0.58 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 63 @437.507s 0%: 0.015+81+0.053 ms clock, 0.031+0.29/0.98/80+0.10 ms cpu, 4->4->1 MB, 5 MB goal, 2 P gc 64 @443.507s 0%: 81+1.2+0.032 ms clock, 162+0.040/1.2/0.44+0.065 ms cpu, 4->4->1 MB, 5 MB goal, 2 P scvg2: inuse: 4, idle: 2, sys: 7, released: 0, consumed: 7 (MB) gc 65 @453.507s 0%: 0.13+81+0.051 ms clock, 0.26+0.20/81/82+0.10 ms cpu, 4->4->1 MB, 5 MB goal, 2 P If I am reading this correctly, some of these STW pauses are 80+ milliseconds, in order to scan a minuscule heap. I am not experienced with debugging the GC in Go, so I'd appreciate any pointers as to why this could happening and what I can do to get to the bottom of the behaviour. Many thanks :) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Trying to understand := and named return values
Ø // Add two numbers
Ø Add(x, y int) int
Although I support documenting functions as you did above, I feel that this
example doesn’t serve your argument well. In this specific case the
counter-argument would be that the documentation adds nothing at all to the
user’s understanding of the function, hence it is superfluous. Indeed, the
documentation doesn’t mention that the two numbers have to be int’s, so I’m
forced to also read the function declaration anyway. It’s like putting a
useless comment on a line of code, for example:
A = A + 1// Add 1 to A
I expect that we can all agree that this comment is not only useless, but is
actually bad since it distracts the user for no benefit.
Regardless, as I said, I do support the documentation line in your example
simply because of human nature. It’s often better to have a rule (all
functions must be preceded by documentation) than to leave it up to the
programmer to decide on a case-by-case basis. The result is higher quality
code overall, I believe.
Let’s look at another example. Which form is better? Which tells the user
more? Which requires less documentation?
Power(x, y int) int
Power(base, exponent int) int
Yes, I think that using named parameters (both calling and return) is good in
general. Yes, there are cases (such as Add) where it doesn’t help, but it also
doesn’t hurt.
John
John Souvestre - New Orleans LA
From: Thomas Bushnell, BSG [mailto:tbushn...@google.com]
Sent: 2017 February 22, Wed 11:01
To: John Souvestre; golang-nuts
Subject: Re: [go-nuts] Re: Trying to understand := and named return values
Function parameters are not a good place (in general - there are exceptions) to
document arguments.
// Frob the outer otter.
FrobOuterOtter(otter Otter)
is not better than
// Frob the outer otter
FrobOuterOtter(Otter)
from the standpoint of external documentation.
But if you want the function to have access to the parameters, you need to name
them. The same is not true for return values.
// Add two numbers
Add(x, y int) int
is fine. This is silly:
// Add two numbers
Add(x, y int) (sum int)
Since the comment already says in English what is returned, there isn't any
value to repeating it again in the return value. Except when there are multiple
ones and the order matters:
// Lookup returns the name and email address of the user.
Lookup(id Identity) (name, email string)
On Tue, Feb 21, 2017 at 6:46 PM John Souvestre <j...@souvestre.com> wrote:
I feel the opposite. I view named returns as documentation of a function's
parameters. I'm constantly amazed by the (correct) emphasis placed on using
appropriate names for calling parameters, but not for the return parameters.
The goal is that I shouldn't have to read a function's code to use the
function, right?
So how can the disparity be justified? Oh, and the longer the function is the
more benefit there is to using them.
John
John Souvestre - New Orleans LA
-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Ian Lance Taylor
Sent: 2017 February 21, Tue 16:13
To: andrew.penneba...@gmail.com
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Trying to understand := and named return values
On Tue, Feb 21, 2017 at 1:46 PM, <andrew.penneba...@gmail.com> wrote:
> Seems like named returns + if/for/switch initializers = a shadowing
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> this is a dangerously subtle problem out there.
Yes, named returns may have been a mistake. Only use them in very
very short functions.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com
<mailto:golang-nuts%2bunsubscr...@googlegroups.com> .
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com
<mailto:golang-nuts%2bunsubscr...@googlegroups.com> .
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Trying to understand := and named return values
Ø does it sounds good to disable (in specs) named return vars shadowing ? This would help, but the := problem isn’t limited to return variables. I think that it’s when there are two (or more) variables, and only one is new, that is the real flaw. I would prefer that it only work when both variables are new. I’ve taken to never using := in any multiple variable situation to avoid the problem. This is something that a ver or lint utility can check for now, too. J John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of djad...@gmail.com Sent: 2017 February 22, Wed 09:35 To: golang-nuts Cc: m...@renich.org Subject: Re: [go-nuts] Re: Trying to understand := and named return values On Wednesday, February 22, 2017 at 3:39:58 PM UTC+2, Marvin Renich wrote: On Tue, Feb 21, 2017 at 1:46 PM, <andrew.p...@gmail.com > wrote: > Seems like named returns + if/for/switch initializers = a shadowing > nightmare. I wish the Go compiler emitted a loud warning on shadowing, as > this is a dangerously subtle problem out there. * Ian Lance Taylor [170221 16:13]: > Yes, named returns may have been a mistake. Only use them in very > very short functions. * John Souvestre <jo...@souvestre.com > [170221 21:46]: > I feel the opposite. I view named returns as documentation of a > function's parameters. I'm constantly amazed by the (correct) > emphasis placed on using appropriate names for calling parameters, but > not for the return parameters. The goal is that I shouldn't have to > read a function's code to use the function, right? I agree with the John and the others that named return variables are a good feature. The confusion is not because of the named returns, but because the := notation used with multiple variables on the left combines declaration and simple assignment without allowing, much less requiring, the programmer to explicitly identify which variables are being declared and which are simply being assigned a new value. This is relevant when := is used at the block scope as well as in if/for/switch initializers. ...Marvin does it sounds good to disable (in specs) named return vars shadowing ? Djadala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Trying to understand := and named return values
Ø Again, named return values are fine and cause no problems, but naked returns should never have been part of the language (at first they seem useful and cool, but in the end, they cause more problems than they solve). I agree. Perhaps in Go 2? J John John Souvestre - New Orleans LA -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Trying to understand := and named return values
I feel the opposite. I view named returns as documentation of a function's parameters. I'm constantly amazed by the (correct) emphasis placed on using appropriate names for calling parameters, but not for the return parameters. The goal is that I shouldn't have to read a function's code to use the function, right? So how can the disparity be justified? Oh, and the longer the function is the more benefit there is to using them. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Ian Lance Taylor Sent: 2017 February 21, Tue 16:13 To: andrew.penneba...@gmail.com Cc: golang-nuts Subject: Re: [go-nuts] Re: Trying to understand := and named return values On Tue, Feb 21, 2017 at 1:46 PM, <andrew.penneba...@gmail.com> wrote: > Seems like named returns + if/for/switch initializers = a shadowing > nightmare. I wish the Go compiler emitted a loud warning on shadowing, as > this is a dangerously subtle problem out there. Yes, named returns may have been a mistake. Only use them in very very short functions. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] 17.3 trace.exe malware flag on win32
I don’t see any problem when I scan it with BitDefender. I’m running the Internet Security 2016 version, build 20.0.29.1550. How about you? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of xiiop...@gmail.com Sent: 2017 February 06, Mon 19:52 To: golang-nuts Subject: [go-nuts] 17.3 trace.exe malware flag on win32 Not sure if this is known but I seem to be getting a malware flag on go/pkg/tool/windows_386/trace.exe ie https://golang.org/pkg/runtime/trace/ of Trojan:Win32/Skeeyah.A!rfn ie https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3aWin32%2fSkeeyah.A!rfn when scanned with windows defender. At first I though I had screwed up because I had installed a few programs recently (maybe I still have..) - but I re-downoaded 1.73 and it detected it again on unzipping No issues on 17.5, assuming a false positive on 1.73 It's definitely coming from https://golang.org/dl/ - the download url https://storage.googleapis.com/golang/go1.7.3.windows-386.zip Can someone double check thanks. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Interesting! Thanks.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Jonas August
Sent: 2017 January 30, Mon 04:25
To: golang-nuts
Subject: Re: [go-nuts] Is Go too strict for nesting function callings?
On Wednesday, January 25, 2017 at 5:48:44 PM UTC-5, John Souvestre wrote:
Does this mean that there is no way to call this function?
func h(func()(int, bool)) {}
No, you can call it by passing in a function value f itself instead of its
result values f(). Using f in the top post:
h(f)// OK
h(f()) // bad
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] GOBIN Question
On Windows I've always had to set GOBIN when doing "go install". If not I get an error message: "go install: no install location for .go files listed on command line (GOBIN not set)". Shouldn't the default GOPATH\bin directory be used in this case? That's what I believe I see described in all three of these: https://golang.org/cmd/go/ https://golang.org/doc/install/source https://github.com/golang/go/wiki/InstallTroubleshooting Is this a bug or am I missing something? John John Souvestre - New Orleans LA -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?
> If you find a piece of code that uses a finaliser for the correct operation > of that program, that code is broken. Does that include using a finalizer with CGO code? From what I read, that seems to be where they are most often used. > https://groups.google.com/forum/#!topic/golang-dev/DMiUkpS1uyQ John John Souvestre - New Orleans LA -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: I know finalizers are not promised to be called, but is it too not promised?
> If finalizers were indeed totally useless, it would obviously be totally
useless to implement support for them.
If someone described a few cases where finalizers were useful perhaps it would
help understand them.
John
John Souvestre - New Orleans LA
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Cross compile GOOS
Hi Jakob. > I don't know the OP's reason, but environment variables are somewhat > more cumbersome on Windows. I don't think there is a way (in cmd) to > do both in one command, for example I believe that this might work. Modifying Dave's example: Set (GOOS=Darwin) & go build The () prevents adding a space to the end of the environment variable. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Jakob Borg Sent: 2017 January 26, Thu 13:13 To: golang-nuts Subject: Re: [go-nuts] Cross compile GOOS I don't know the OP's reason, but environment variables are somewhat more cumbersome on Windows. I don't think there is a way (in cmd) to do both in one command, for example. Maybe in Powershell, I don't speak it, but commands tend to look quite verbose there as well. //jb > On 26 Jan 2017, at 19:17, Dave MacFarlane <driu...@gmail.com> wrote: > > "BSD" isn't a valid OS. It's a family of OSes.. but why don't you just > set the environment variable while running the command? > > Such as: >GOOS=dragonfly go build prog > >> On Thu, Jan 26, 2017 at 1:10 PM, <yout...@z505.com> wrote: >> Is there any way to cross compile without setting GOOS environment variable? >> >> i.e. something like >> >> go build os=bsd prog >> >> Or is it by design that you cannot just compile using a compiler switch, you >> must set GOOS environment variable? >> >> Thanks >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Hi Dave.
> The blame for this confusion comes from adding the special case, not from a
> limitation of the general function call syntax.
I see it differently. The limitation I'm referring to is "… arguments must be
single-valued expressions assignable to the parameter types of F …". I believe
that without this limitation both cases would work, no “special case” exception
would be needed, higher-order functions would be more fully implemented, and Go
would be more orthogonal.
The only downside is what Ian pointed out – potential confusion when used with
variadac functions. But worst case an exception could handle this. J
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2017 January 25, Wed 22:12
To: golang-nuts
Subject: Re: [go-nuts] Is Go too strict for nesting function callings?
I think you misunderstand. The exception is this form
func f() (int, boo)
func g1(int, bool)
g1(f())
Not this form
func g2(int, int, bool)
g2(1, f())
The exception is the former form which is a special case for convenience. This
special case creates confusion when people try the second form. The blame for
this confusion comes from adding the special case, not from a limitation of the
general function call syntax.
On Thursday, 26 January 2017 12:28:34 UTC+11, John Souvestre wrote:
Hi Ian.
OK, I understand now.
Btw - I wasn't proposing adding an exception, but removing a limitation and the
exception due to it. :)
John
John Souvestre - New Orleans LA
-Original Message-
From: Ian Lance Taylor [mailto:ia...@golang.org ]
Sent: 2017 January 25, Wed 19:18
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Is Go too strict for nesting function callings?
On Wed, Jan 25, 2017 at 5:05 PM, John Souvestre <jo...@souvestre.com
> wrote:
>
> Thanks! I see both the limitation and the exception.
>
> Other than implementation complexity, is there a reason for the limitation of
> single-valued expressions? Is there some fundamental problem with allowing
> multi-valued expressions that I'm missing?
It's potentially confusing when used with variadic functions. If we
extend past function calls, it's potentially confusing when used with
multi-valued assignment statements. It's hard to make fully general
while avoiding confusion, and specific uses don't seem to arise often
enough in practice to justify adding more exceptions to the language.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Hi Ian. OK, I understand now. Btw - I wasn't proposing adding an exception, but removing a limitation and the exception due to it. :) John John Souvestre - New Orleans LA -Original Message- From: Ian Lance Taylor [mailto:i...@golang.org] Sent: 2017 January 25, Wed 19:18 To: John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] Is Go too strict for nesting function callings? On Wed, Jan 25, 2017 at 5:05 PM, John Souvestre <j...@souvestre.com> wrote: > > Thanks! I see both the limitation and the exception. > > Other than implementation complexity, is there a reason for the limitation of > single-valued expressions? Is there some fundamental problem with allowing > multi-valued expressions that I'm missing? It's potentially confusing when used with variadic functions. If we extend past function calls, it's potentially confusing when used with multi-valued assignment statements. It's hard to make fully general while avoiding confusion, and specific uses don't seem to arise often enough in practice to justify adding more exceptions to the language. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Hi Caleb. Thanks! I see both the limitation and the exception. Other than implementation complexity, is there a reason for the limitation of single-valued expressions? Is there some fundamental problem with allowing multi-valued expressions that I'm missing? John John Souvestre - New Orleans LA -Original Message- From: Caleb Spare [mailto:cesp...@gmail.com] Sent: 2017 January 25, Wed 18:46 To: John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] Is Go too strict for nesting function callings? https://golang.org/ref/spec#Calls Look for "As a special case, if the return values of a function or method g are equal in number" On Wed, Jan 25, 2017 at 4:42 PM, John Souvestre <j...@souvestre.com> wrote: > Then I'm still confused. Where is this inconsistency / limitation / > non-orthogonal "syntactic sugar" defined? I'm trying to understand why it > exists if perhaps it isn't necessary. > > John > > John Souvestre - New Orleans LA > > > -Original Message- > From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On > Behalf Of Dave Cheney > Sent: 2017 January 25, Wed 18:30 > To: golang-nuts > Subject: RE: [go-nuts] Is Go too strict for nesting function callings? > > It was just a turn of phrase, it's not a real rule. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Then I'm still confused. Where is this inconsistency / limitation / non-orthogonal "syntactic sugar" defined? I'm trying to understand why it exists if perhaps it isn't necessary. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 January 25, Wed 18:30 To: golang-nuts Subject: RE: [go-nuts] Is Go too strict for nesting function callings? It was just a turn of phrase, it's not a real rule. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Hi Dave. I believe that the example I posed is more fundamental, but along the same lines, than the one posed by TL. Perhaps not... Regardless, what is the rule you referred to? And is there any disadvantage to allowing the "syntactic sugar" to work in all cases? John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 January 25, Wed 18:06 To: golang-nuts Subject: RE: [go-nuts] Is Go too strict for nesting function callings? I think you're talking about a different example to TL. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Priority cases in select?
Hi Val. Yes! Not all software races are critical. I would say that this is an example of a non-critical one, depending on your needs (is 1us resolution good enough?). The only software method of synchronizing events absolutely would probably would require locking the CPU's interrupts. :) Digital designers generally classify races as either critical (bad) or non-critical (not bad). Indeed, some non-critical races are necessary else things wouldn't work. :) John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Val Sent: 2017 January 25, Wed 16:40 To: golang-nuts Subject: Re: [go-nuts] Re: Priority cases in select? Thank you John and Paul, I find this debate really interesting. > hi was clearly written before lo This is not my understanding of the memory model : because the channels are buffered, I can't really infer the "happens-before" relationship between the reading event of the channels. And even if the relationship holds locally in the writing side, it has no strong implication on what other goroutines can see. I would say the hi and lo communications happen concurrently, hence the "wrong" results once in a while. Val -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Priority cases in select?
Hi Paul.
I looked at your code a bit more. I believe that there might be another
problem. The call to “next” is concurrent with the setting of hi and low.
This means that “next” might get through the first select, get paused, hi and
low be set, then “next” continues and executes the second select. In this
case, the result is nondeterministic – as expected. To “next” it appears that
hi and low were set at the same time.
If you ensure that next does have a chance to run between when hi gets set and
when low gets set, then it works deterministically. You could put a 1ms sleep
between them, for example. Even a “runtime.Gosched()” helps – but it isn’t a
guarantee.
How close together can the hi and low settings be without there being a race?
There is no guaranteed safe interval, but on my machine 1ms was good enough
that there were no “failures” within a one minute test run. On Windows I can’t
sleep for less than 1ms, but I suspect that the real answer is more like 1us
for practical (not absolutely guaranteed) usage. This is assuming the CPU
isn’t loaded, too. J
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:j...@souvestre.com]
Sent: 2017 January 25, Wed 17:02
To: 'golang-nuts'
Subject: RE: [go-nuts] Re: Priority cases in select?
I believe that there is a typo in your example. It seems that you have
separate selects instead of nested selects.
Try: https://play.golang.org/p/YWYhnLJsdS
John
John Souvestre - New Orleans LA
From: Paul Borman [mailto:bor...@google.com]
Sent: 2017 January 25, Wed 16:01
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
I originally was thinking on the lines of what John said, but I proved it
wrong, see https://play.golang.org/p/JwX_cxaR99 for the code. You can't run it
in the playground, but on my MacPro I get output like:
$ GOMAXPROCS=1 go run r.go
Failed after 1137702
Failed after 699376
Failed after 757658
^Csignal: interrupt
$ GOMAXPROCS=2 go run r.go
Failed after 12954
Failed after 63778
Failed after 11831
Failed after 277038
^Csignal: interrupt
So even though hi was clearly written before lo, it is possible to fail the
first select, have hi and lo written (in that order), and then enter the second
select which has a 50% chance on reading from lo, even with GOMAXPROCS set to 1.
On Wed, Jan 25, 2017 at 11:27 AM, John Souvestre <j...@souvestre.com> wrote:
I understand what you are saying, but all of these situations are basically
race conditions, aren’t they? So there is no deterministic manner of resolving
them. Thus it doesn’t matter which is chosen. However, in the more general,
non-race, condition I believe that it meets the goals.
John
John Souvestre - New Orleans LA
From: Axel Wagner [mailto:axel.wagner...@googlemail.com]
Sent: 2017 January 25, Wed 13:19
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
Doesn't work. If no communication can proceed when entering the select, this
degenerates to a simple select. For example, say there are no writers to any of
those channels. At the same time, that the last select is entered, three
different goroutines start blocking to write to one of the channels each. Even
though priorityHigh could proceed, you will read from one of the other with ⅔
probability.
(a simpler case: Imagine that, while the goroutine is blocking in the innermost
select, a second goroutines enters *the same* select, just with writes.
Semantically, all three communications can proceed at the same time for both
goroutines, so one is chosen uniformly)
This is the fundamental problem with all the nested select solutions; they
assume that the code is evaluated atomically. But in reality, the state of a
communication being possible can change at any point for an arbitrary number of
channels. Thus, you can always construct a sequence where you revert to the
innermost select, violating c.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Priority cases in select?
I believe that there is a typo in your example. It seems that you have
separate selects instead of nested selects.
Try: https://play.golang.org/p/YWYhnLJsdS
John
John Souvestre - New Orleans LA
From: Paul Borman [mailto:bor...@google.com]
Sent: 2017 January 25, Wed 16:01
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
I originally was thinking on the lines of what John said, but I proved it
wrong, see https://play.golang.org/p/JwX_cxaR99 for the code. You can't run it
in the playground, but on my MacPro I get output like:
$ GOMAXPROCS=1 go run r.go
Failed after 1137702
Failed after 699376
Failed after 757658
^Csignal: interrupt
$ GOMAXPROCS=2 go run r.go
Failed after 12954
Failed after 63778
Failed after 11831
Failed after 277038
^Csignal: interrupt
So even though hi was clearly written before lo, it is possible to fail the
first select, have hi and lo written (in that order), and then enter the second
select which has a 50% chance on reading from lo, even with GOMAXPROCS set to 1.
On Wed, Jan 25, 2017 at 11:27 AM, John Souvestre <j...@souvestre.com> wrote:
I understand what you are saying, but all of these situations are basically
race conditions, aren’t they? So there is no deterministic manner of resolving
them. Thus it doesn’t matter which is chosen. However, in the more general,
non-race, condition I believe that it meets the goals.
John
John Souvestre - New Orleans LA
From: Axel Wagner [mailto:axel.wagner...@googlemail.com]
Sent: 2017 January 25, Wed 13:19
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
Doesn't work. If no communication can proceed when entering the select, this
degenerates to a simple select. For example, say there are no writers to any of
those channels. At the same time, that the last select is entered, three
different goroutines start blocking to write to one of the channels each. Even
though priorityHigh could proceed, you will read from one of the other with ⅔
probability.
(a simpler case: Imagine that, while the goroutine is blocking in the innermost
select, a second goroutines enters *the same* select, just with writes.
Semantically, all three communications can proceed at the same time for both
goroutines, so one is chosen uniformly)
This is the fundamental problem with all the nested select solutions; they
assume that the code is evaluated atomically. But in reality, the state of a
communication being possible can change at any point for an arbitrary number of
channels. Thus, you can always construct a sequence where you revert to the
innermost select, violating c.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is Go too strict for nesting function callings?
Hi Dave.
I'm trying to understand this. What is the rule?
Does this mean that there is no way to call this function?
func h(func()(int, bool)) {}
Is there any disadvantage to not allowing the "syntactic sugar" to work in all
cases?
John
John Souvestre - New Orleans LA
-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2017 January 25, Wed 15:42
To: golang-nuts
Subject: [go-nuts] Is Go too strict for nesting function callings?
The confusion comes, like most cases in go, where a little syntactic sugar has
been added to make the common case more appealing, but has the side effect of
making the less common case more jarring.
g1(f())
Is th exception to the rule. By _not_ requiring the caller to capture each
value from evaluating f() by hand before calling g1.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Priority cases in select?
I understand what you are saying, but all of these situations are basically race conditions, aren’t they? So there is no deterministic manner of resolving them. Thus it doesn’t matter which is chosen. However, in the more general, non-race, condition I believe that it meets the goals. John John Souvestre - New Orleans LA From: Axel Wagner [mailto:axel.wagner...@googlemail.com] Sent: 2017 January 25, Wed 13:19 To: John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] Re: Priority cases in select? Doesn't work. If no communication can proceed when entering the select, this degenerates to a simple select. For example, say there are no writers to any of those channels. At the same time, that the last select is entered, three different goroutines start blocking to write to one of the channels each. Even though priorityHigh could proceed, you will read from one of the other with ⅔ probability. (a simpler case: Imagine that, while the goroutine is blocking in the innermost select, a second goroutines enters *the same* select, just with writes. Semantically, all three communications can proceed at the same time for both goroutines, so one is chosen uniformly) This is the fundamental problem with all the nested select solutions; they assume that the code is evaluated atomically. But in reality, the state of a communication being possible can change at any point for an arbitrary number of channels. Thus, you can always construct a sequence where you revert to the innermost select, violating c. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Priority cases in select?
> I don't believe the actual use case described can be mapped. From what I
> understand, the intended behavior was
> a) put the goroutine to sleep until some communication can proceed
> b) if exactly one communication can proceed, do it
> c) if multiple communications can proceed, choose the one with the highest
> priority
How about:
select {
case <-priorityHigh:
...
default:
select {
case <-priorityLow:
...
default:
select {
case <- priorityHigh:
...
case <- priorityLow:
...
case <- priorityLowest:
...
}
}
}
John
John Souvestre - New Orleans LA
From: 'Axel Wagner' via golang-nuts [mailto:golang-nuts@googlegroups.com]
Sent: 2017 January 25, Wed 10:00
To: Egon
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
I don't believe the actual use case described can be mapped. From what I
understand, the intended behavior was
a) put the goroutine to sleep until some communication can proceed
b) if exactly one communication can proceed, do it
c) if multiple communications can proceed, choose the one with the highest
priority
The suggested solutions (or any I can think of) violate at least one of these.
They either wait busily, violating a, or they try to communicate in
priority-order, then, as a last resort, block on any particular case, violating
b, or they fall back to a regular select, violating c.
I don't know enough about how select is implemented to pass any judgement on
whether this can be efficiently implemented, but I'm also not sure it's such a
great idea. Choosing a case uniformly at random was a deliberate design
decision to prevent starvation. There is a certain danger in people not
realizing that they become susceptible to starvation if they do this. It's also
a feature rabbit-hole
<https://commandcenter.blogspot.ch/2012/06/less-is-exponentially-more.html> .
I'd predict, that next up, someone who experiences starvation wants to add
weighted scheduling ("give this case an 80% chance of succeeding and this other
case 20%, so that eventually either will proceed") or more complicated
scheduling strategies.
I think such edge-cases for scheduling requirements should rather be
implemented separately in a library. Yes, it's complicated code, but that's all
the more reason why it shouldn't be in everyone's go runtime.
On Wed, Jan 25, 2017 at 4:23 PM, Egon <egonel...@gmail.com> wrote:
On Wednesday, 25 January 2017 15:14:27 UTC+2, T L wrote:
sometimes, I do want one case on a select block get selected even if there are
multiple unblocked cases.
For example, I don't want the dataCh case is selected if the stopCh and the
timer channel are unblocked:
select {
case <- stopCh:
return
case value := <-dataCh:
}
select {
case <- time.After(time.Second):
return
case dataCh <- value:
}
Is there a solution to satisfy my need currently?
type poller func() bool
var pollers []poller
pollers = append(pollers, func() bool {
select {
case <-priority:
// ...
default:
return false
}
return true
})
for {
for _, p := range pollers {
if p() {
break
}
}
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
An afterthought: For the “done” case, add a check to clear out any “cs” values
which might come in just before the “done” signal. You won’t need to worry
about this in the “timeout” case.
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:j...@souvestre.com]
Sent: 2017 January 08, Sun 07:27
To: 'golang-nuts'
Subject: RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I’m thinking something like this might do the job. Call monitorWorker(wg,
done) as a goroutine and change it to do just the wg.Wait then send a signal on
the “done” channel.
Next, start a goroutine which signals on a “timeout” channel if the timeout is
exceeded.
Finally, change GetWorkerValues to be an endless loop containing a select with
three cases: “<-cs” (add new value to array), “<-done” (break), and “<-timeout”
(break). After the loop, send the array.
John
John Souvestre - New Orleans LA
From: desaiabhi...@gmail.com [mailto:desaiabhi...@gmail.com]
Sent: 2017 January 08, Sun 07:10
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi John
Can you please help me to apply correct logic to achieve it
Haven't found any solution on the net. All articles are talking about only 1
routine timeout and not multiple
Thank you very much
Rgds
Abhi
On Jan 8, 2017, at 6:36 PM, John Souvestre <j...@souvestre.com> wrote:
Hi Abhi.
I believe that your logic is faulty. The timeout does take place – but it
doesn’t really do what you wanted, I think.
GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
finish until the channel is closed. The channel is not closed until both
workers are finished – timeout or not, thus it always contains the info for
both workers.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 06:24
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and not
2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i<len(headers);i++ {
fmt.Printf("Name > %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works but
dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I’m thinking something like this might do the job. Call monitorWorker(wg,
done) as a goroutine and change it to do just the wg.Wait then send a signal on
the “done” channel.
Next, start a goroutine which signals on a “timeout” channel if the timeout is
exceeded.
Finally, change GetWorkerValues to be an endless loop containing a select with
three cases: “<-cs” (add new value to array), “<-done” (break), and “<-timeout”
(break). After the loop, send the array.
John
John Souvestre - New Orleans LA
From: desaiabhi...@gmail.com [mailto:desaiabhi...@gmail.com]
Sent: 2017 January 08, Sun 07:10
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi John
Can you please help me to apply correct logic to achieve it
Haven't found any solution on the net. All articles are talking about only 1
routine timeout and not multiple
Thank you very much
Rgds
Abhi
On Jan 8, 2017, at 6:36 PM, John Souvestre <j...@souvestre.com> wrote:
Hi Abhi.
I believe that your logic is faulty. The timeout does take place – but it
doesn’t really do what you wanted, I think.
GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
finish until the channel is closed. The channel is not closed until both
workers are finished – timeout or not, thus it always contains the info for
both workers.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 06:24
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and not
2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i<len(headers);i++ {
fmt.Printf("Name > %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works but
dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
p
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I believe that your logic is faulty. The timeout does take place – but it
doesn’t really do what you wanted, I think.
GetWorkerValues isn’t going to send it’s info because the “range cs” can’t
finish until the channel is closed. The channel is not closed until both
workers are finished – timeout or not, thus it always contains the info for
both workers.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 06:24
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
I am expecting work2 should not include in
headers = <-messgesResponse
so output of below should be Len = 1 and should print only work 1 only and not
2 ( as work 2 is timed out )
fmt.Printf("len > %s\n", len(headers))
for i:=0;i<len(headers);i++ {
fmt.Printf("Name > %s\n", headers[i].Name)
}
basically workgroup timeout doesnt close the timeout works
select {
case <-time.After(2 * time.Second): //This works but
dont stop the work2
return
}
Do I need to explicitly close them in
select {
case <-time.After(2 * time.Second):
close(cs)
return
}
Thanks for the help
Rgds,
Abhi
On Sunday, January 8, 2017 at 5:40:01 PM UTC+5:30, John Souvestre wrote:
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
"sync"
)
type TestStruct struct {
Name string
}
func main() {
wg := {}
messges := make(chan *TestStruct, 1)
wg.Add(1)
go Work1(messges, wg, "1")
wg.Add(1)
go Work2(messges, wg, "2")
monitorWorker(wg, messges)
messgesResponse := make(chan []*TestStruct)
go GetWorkerValues(messges, messgesResponse)
headers := make([]*TestStruct, 0)
headers = <-messgesResponse
fmt.Printf("len > %s\n", len(headers))
for i:=0;i<len(headers);i++ {
fmt.Printf("Name > %s\n", headers[i].Name)
}
}
func monitorWorker(wg *sync.WaitGroup, cs chan *
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi again.
Did you perhaps intend to make the call to monitorWorker() as a goroutine?
That would let it run in parallel with the rest of main.
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:j...@souvestre.com]
Sent: 2017 January 08, Sun 06:10
To: 'golang-nuts'
Subject: RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
Hi Abhi.
I believe that the wait group timeout (in monitorWorker) was set to 2 seconds
in the code you posted.
I put a debugging print in the timeout case, and it is taking place.
What were you expecting to see?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 05:48
To: golang-nuts
Subject: Re: [go-nuts] Multiple goroutine timeout for waitgroup not working
hi John
Thanks for the reply
sorry
I mean Work2 takes => 3 seconds
work1 takes => 1 seconds
Wait group timeout is => 1 seconds
It is expected that only Work1 should get done and Work 2 should get timeout
which is not happening
Waitgroup waits for both work.. program doing something wrong
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(3 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
Thanks,
Abhi
On Sunday, January 8, 2017 at 5:09:56 PM UTC+5:30, John Souvestre wrote:
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of
desaia...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
"sync"
)
type TestStruct struct {
Name string
}
func main() {
wg := {}
messges := make(chan *TestStruct, 1)
wg.Add(1)
go Work1(messges, wg, "1")
wg.Add(1)
go Work2(messges, wg, "2")
monitorWorker(wg, messges)
messgesResponse := make(chan []*TestStruct)
go GetWorkerValues(messges, messgesResponse)
headers := make([]*TestStruct, 0)
headers = <-messgesResponse
fmt.Printf("len > %s\n", len(headers))
for i:=0;i<len(headers);i++ {
fmt.Printf("Name > %s\n", headers[i].Name)
}
}
func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
go func() {
defer close(cs)
wg.Wait()
}()
select {
case <-time.After(2 * time.Second):
return
}
}
func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func GetWorkerValues(cs <-chan *TestStruct, response chan<- []*TestStruct) {
var val []*TestStruct
for header := range cs {
val = append(val, header)
}
response <- val
}
Thanks,
Abhi
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang
RE: [go-nuts] Multiple goroutine timeout for waitgroup not working
What do you see when you run it? I see:
finished 1
finished 2
len > %!s(int=2) ç Using a string format for an int
Name > 1
Name > 2
Ø Work 2 - have 3 second
I’m not sure exactly what you are trying to do, but I suspect that changing
“messges” to hold 2 items might make it work.
messges := make(chan *TestStruct, 2)
I’m guessing, but I suspect that you didn’t realize that if Work1 runs first,
then Work2 will block since the channel is full (or until you close it).
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of desaiabhi...@gmail.com
Sent: 2017 January 08, Sun 01:23
To: golang-nuts
Subject: [go-nuts] Multiple goroutine timeout for waitgroup not working
Can you please help to correct below program where timeout not seems working
Work 1 - have 1 second
Work 2 - have 3 second
Total Timeout - 2 sec
program wait for entire 3 seconds and return both values rather than value from
Work 1
Program >
package main
import (
"fmt"
"time"
"sync"
)
type TestStruct struct {
Name string
}
func main() {
wg := {}
messges := make(chan *TestStruct, 1)
wg.Add(1)
go Work1(messges, wg, "1")
wg.Add(1)
go Work2(messges, wg, "2")
monitorWorker(wg, messges)
messgesResponse := make(chan []*TestStruct)
go GetWorkerValues(messges, messgesResponse)
headers := make([]*TestStruct, 0)
headers = <-messgesResponse
fmt.Printf("len > %s\n", len(headers))
for i:=0;i<len(headers);i++ {
fmt.Printf("Name > %s\n", headers[i].Name)
}
}
func monitorWorker(wg *sync.WaitGroup, cs chan *TestStruct) {
go func() {
defer close(cs)
wg.Wait()
}()
select {
case <-time.After(2 * time.Second):
return
}
}
func Work1(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func Work2(message chan *TestStruct, wg *sync.WaitGroup, tokenNumber string) {
defer wg.Done()
v1 := new(TestStruct)
v1.Name = tokenNumber
time.Sleep(1 * time.Second)
message <- v1
fmt.Printf("finished %s\n", tokenNumber)
}
func GetWorkerValues(cs <-chan *TestStruct, response chan<- []*TestStruct) {
var val []*TestStruct
for header := range cs {
val = append(val, header)
}
response <- val
}
Thanks,
Abhi
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: too many runtime.gcBgMarkStartWorkers ?
Ø Any insight into why setting GOMAXPROCS > numCPU is a win might lead to
improving the Go scheduler or perhaps Go / OS interaction.
I’ve found it useful if you happen to have a number of compute-bound goroutines
which don’t reschedule. Setting more processes than CPUs causes the kernel to
do some scheduling for them.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of r...@golang.org
Sent: 2016 December 30, Fri 09:53
To: golang-nuts
Subject: [go-nuts] Re: too many runtime.gcBgMarkStartWorkers ?
The default is GOMAXPROCS == numCPU and the runtime is optimized and tested for
this. There are use cases involving co-tenancy where setting GOMAXPROCS <
numCPU tells the OS to limit HW allocation and improves overall throughput when
several programs are running concurrently.
Setting GOMAXPROCS > numCPU seems to indicate that the Go scheduler and the OS
scheduler are out of sync. Perhaps the delay between the OS knowing a call is
blocked and the Go scheduler knowing it is blocked is the root cause. Any
insight into why setting GOMAXPROCS > numCPU is a win might lead to improving
the Go scheduler or perhaps Go / OS interaction.
On Wednesday, December 28, 2016 at 3:41:31 PM UTC-5, Dave Cheney wrote:
There may be a bug here. IMO the runtime should never try to start more that
numCPUs background workers regardless of the size of GOMAXPROCS as that'll just
cause contention during the GC cycle.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Most efficient way to implement PubSub pattern using channels
What is a partitioned channel? John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Zeeshan Arif Sent: 2016 December 25, Sun 19:05 To: golang-nuts Subject: [go-nuts] Most efficient way to implement PubSub pattern using channels Maybe it's because you have 1outbound channel per user, is there anyway to have a partitioned channel? -zeesh49 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Idiomatic way to remove duplicates in a slice
Ø there is good gist. Ø this algorithm 10x faster … I don’t believe it is faster as the slice size increases. What you propose is O(N**2) vs O(N). Try a test with a slice 10 or 100 times the size. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of ali oygur Sent: 2016 December 14, Wed 05:41 To: golang-nuts Subject: [go-nuts] Re: Idiomatic way to remove duplicates in a slice there is good gist. https://gist.github.com/alioygur/16c66b4249cb42715091fe010eec7e33 12 Ağustos 2012 Pazar 06:33:54 UTC+4 tarihinde Sathish VJ yazdı: Is there an efficient, idiomatic way to remove duplicates in a slice? If possible, I do want to retain the original order of items. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Is it a compiler bug?
Ø Also, prefixing all of the need-to-be-commented-out lines with // is always safe: https://play.golang.org/p/8Cot8lssO3 Except for perhaps: https://play.golang.org/p/9xiWFI-SgB John -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: My Computer compiles go slower than my friends worse laptop
You might add the Go directories/exe's to the exclusion list which most AV programs have. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Henry Sent: 2016 November 06, Sun 19:08 To: golang-nuts Subject: [go-nuts] Re: My Computer compiles go slower than my friends worse laptop Anti virus software is also a possible culprit. I used to run bitdefender free on my windows machine. When I switched to Kaspersky, there is a noticeable slowdown when running go build and go test. However, it is still within an acceptable margin, so it's okay for me. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Compiler level memory barrier in Go i.e. asm volatile("" : : : "memory")
+1
Please note my new email address: j...@souvestre.com
John
John Souvestre - New Orleans LA
-Original Message-
From: Ian Lance Taylor [mailto:i...@golang.org]
Sent: 2016 November 04, Fri 17:09
To: tsuna
Cc: Rob Pike; John Souvestre; golang-nuts; Dmitry Vyukov
Subject: Re: [go-nuts] Compiler level memory barrier in Go i.e. asm volatile(""
: : : "memory")
On Fri, Nov 4, 2016 at 3:01 PM, tsuna <tsuna...@gmail.com> wrote:
>
> Follow up question, just to be sure:
>
> Do we then agree that if I see code like this:
>
> for {
> version := shmem.version // this reads a uint32 from shared memory
> doSomething()
> if version == shmem.version {
> break
> }
> }
>
> then this code is buggy because the Go compiler could re-order the
> code or factor out the subexpression �shmem.version�, or the CPU could
> even potentially execute things out of order? i.e. the only way to
> make this code correct is to atomic.LoadUint32(), right?
Right (and of course modify shmem.version using atomic.StoreUint32).
> I think until recently the Go compiler wasn�t optimizing much (before
> the SSA work started, was gc doing any kind of common subexpression
> elimination or whatnot?), but now that this is changing (fast), I�m
> finding more code following this pattern and I want to be 100% certain
> I can say �this is buggy, we need to change this�.
Note that it's not just the compiler. As I was saying on another
thread earlier today, it's also the memory ordering of the processor.
Without using the atomic functions, nothing ensures that that the core
reading shmem.version will also see the other values written into
memory before shmem.version was written. In this case that may not
matter, but often it does.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Custom collation
I’m thinking that the standard library’s sort would do the job. You would need to supply 3 functions for your data: Len, Swap, and Less. You could implement Less to incorporate your collation scheme. One other idea: Using an array to define the collating order sounds good, but it would require a binary search for each lookup. After building the array, how about using it to build a map which would connect each of the entries to its order number – a “reversed” array, so to speak. This would reduce the lookup time from O(log n) to O(1). John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Jonathan Hall Sent: 2016 October 31, Mon 17:36 To: golang-nuts Subject: [go-nuts] Custom collation I need to collate some IPA transcriptions, which means that following the standard collation rules for a given language doesn't really make sense. As such, I wish to define my own collation order. Is there any documentation, howto, or other easier-to-digest documentation on this than what can be found in the colltab godoc (https://godoc.org/golang.org/x/text/internal/colltab) ? Or is there a better way to accomplish my goal? For those interested, in the details: I wish to order by mouth position, so collation order would be something like: pbtdʈɖcɟ... iyɨʉ... So right off the bat, the ordering is pretty close to random, with respect to normal alphabetization. My initial implementation simply defines the order of the expected phonemes in a sorted array, and sorts on this position. But this is very limited, doesn't scale, and doesn't account for unanticipated phoneme modifiers or diphthongs. So the collate package & friends seem like the natural tools for this job. Am I on the right track here? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?
Take a look at https://github.com/LK4D4/trylock/blob/master/trylock.go . I believe that it is easier and performs better. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of djad...@gmail.com Sent: 2016 October 23, Sun 10:30 To: golang-nuts Subject: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ? Hi, Trylock is simple as: https://play.golang.org/p/rpy3Kg1KWW Regards, Djadala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?
I understand what you are saying with regard to a reentrant type of mutex. But
how about a non-reentrant mutex, as Go currently has? Borrowing from an old
message by Luke Scott:
> I was looking at the sync package's Lock function, and it does
> almost the same thing.
> It looks like a TryLock function would look like this:
>
> func (m *Mutex) TryLock() bool {
> return atomic.CompareAndSwapInt32(, 0, mutexLocked)
> }
>
> Is this correct? If so, what's the problem?
I don’t recall seeing an answer to his question, however.
John
John Souvestre - New Orleans LA
From: adonovan via golang-nuts [mailto:golang-nuts@googlegroups.com]
Sent: 2016 October 23, Sun 07:39
To: golang-nuts
Subject: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar
method ?
On Friday, 21 October 2016 09:05:10 UTC-4, Michael Liu wrote:
I've a race scenario used with Mutex.Lock with Lock() and Unlock(). now
multi-routines try to lock the resource and start a few logical code if the
Lock.Lock() succesfully. other routines don't need to block util Lock.Unlock()
that they can do the above logicals with next time or in future(logical may
changes some variables and those variables' change could be see with latency).
That looks like a Trylock() implemetion.
One reason the TryLock method does not exist is that its behavior cannot be
expressed without reference to some notion of goroutine identity. That is, its
doc comment would read "succeeds immediately if the current goroutine already
holds the lock". The designers of the language have strived to avoid making
goroutine state relevant to the behavior of any function since it makes
programs had to reason about and prevents programmers from freely moving work
to a different goroutine.
Another reason is described in Chapter 9 of our book (gopl.io): "There is a
good reason Go’s mutexes are not re-entrant. The purpose of a mutex is to
ensure that certain invariants of the
shared variables are maintained at critical points during program execution.
One of the invariants is “no goroutine is accessing the shared variables,” but
there may be additional invariants specific to the data structures that the
mutex guards. When a goroutine acquires a mutex lock, it may assume that the
invariants hold. While it holds the lock, it may update the shared variables so
that the invariants are temporarily violated. However, when it releases the
lock, it must guarantee that order has been restored and the invariants hold
once again. Although a re-entrant mutex would ensure that no other goroutines
are accessing the shared variables, it cannot protect the additional invariants
of those variables."
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
I see that Ian has already answered your question.
> But the crucial point is that this is an implicit and unspecified (as in
> "not in the spec") property of those operations.
Although not very verbose, I believe that the Go Memory Model (as I quoted
earlier) is the guarantee. And I believe that this statement is meant to cover
both CPU and compiler ordering.
John
John Souvestre - New Orleans LA
-Original Message-
From: Konstantin Khomoutov [mailto:flatw...@users.sourceforge.net]
Sent: 2016 October 12, Wed 11:40
To: John Souvestre
Cc: 'golang-nuts'
Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java
equivalent, program spends most of time in sync.(*Mutex).Lock() and
sync.(*Mutex).Unlock()
On Wed, 12 Oct 2016 07:36:15 -0500
John Souvestre <j...@souvestre.com> wrote:
> Interesting. I didn�t realize that thread was live again. I thought
> that this one put it to rest.
> https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ
>
> I don�t know for sure, but I imagine that Russ� statement about
> atomics was mainly concerning synchronization � which Go�s
> sync/atomic operations provide. And I would certainly agree.
I surely maybe completely wrong in interpreting what Henrik Johansson
tries to express but I think I share confusion with him on this point so
let me try to express it in different words.
I assume you're correct that on today's popular H/W architectures
functions of the sync/atomic package emit a memory barrier and hence
stuff like
// goroutine 1
data = 42
atomic.StoreInt32(, 1)
// goroutine 2
for {
if atomic.CompareAndSwapInt32(, 1, 0) {
break
}
runtime.Gosched()
}
if data != 42 {
panic("broken")
}
works because those memory barriers are full�and hence "global".
But the crucial point is that this is an implicit and unspecified
(as in "not in the spec") property of those operations.
I, for one, can't see why atomic.Store() has to issue a full memory
barrier at all: as I understand the sole guarantee of its "atomicity"
property is that no reader of the affected memory region will observe a
so-called "partial update" when atomic.Store() performs that update.
Now suppose some (future or existing) H/W arch would allow maintaining
this "readers see no partial update" invariant while not issuing a
memory fence. In this case the value read from the "data" variable in
the second goroutine in the example above may legitimately be != 42.
To rephrase, I fail to see how a pair of store/CAS functions from
sync/atomic enforce the "happens before" relationship on anything
except the precise memory region under a variable they operate on.
To quote the Wikipedia article on memory barriers [1]:
| Some architectures, including the ubiquitous x86/x64, provide several
| memory barrier instructions including an instruction sometimes called
| "full fence". A full fence ensures that all load and store operations
| prior to the fence will have been committed prior to any loads and
| stores issued following the fence. Other architectures, such as the
| Itanium, provide separate "acquire" and "release" memory barriers
| which address the visibility of read-after-write operations from the
| point of view of a reader (sink) or writer (source) respectively.
| Some architectures provide separate memory barriers to control
| ordering between different combinations of system memory and I/O
| memory. When more than one memory barrier instruction is available it
| is important to consider that the cost of different instructions may
| vary considerably.
So, above I was actually referring to those �separate "acquire" and
"release" memory barriers�.
Could you please clear this confusion up for me?
1. https://en.wikipedia.org/wiki/Memory_barrier
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
Ø . The only reason I hesitate to go further is because that isn't formalized
as part of the spec I don't believe, hence the issue.
I believe it is. From the Go Memory Model:
“To serialize access, protect the data with channel operations or other
synchronization primitives such as those in the <https://golang.org/pkg/sync/>
sync and <https://golang.org/pkg/sync/atomic/> sync/atomic packages.”
John
John Souvestre - New Orleans LA
From: hiatt.dus...@gmail.com [mailto:hiatt.dus...@gmail.com]
Sent: 2016 October 12, Wed 09:05
To: golang-nuts
Cc: j...@souvestre.com
Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java
equivalent, program spends most of time in sync.(*Mutex).Lock() and
sync.(*Mutex).Unlock()
I think what Russ is saying there is don't do
// routine 1
x = 5
// routine 2
atomic.LoadInt32()
That's mixing atomic operations on the same word. In the case of a spin lock
to coordinate threads, Dmitriy's comment 15 is illustrative:
1.
// goroutine 1
data = 42
atomic.Store(, 1)
// goroutine 2
if atomic.Load() {
if data != 42 {
panic("broken")
}
}
I'm pretty sure the above case works in go without panicking and there is
causal ordering here. The only reason I hesitate to go further is because that
isn't formalized as part of the spec I don't believe, hence the issue.
On Wednesday, October 12, 2016 at 6:16:00 AM UTC-5, Henrik Johansson wrote:
I am sorry if I am dense but what Russ said in that thread "and that you
shouldn't mix atomic and non-atomic accesses for a given memory word" seems to
indicate otherwise.
I am not going to use spin locks left and right but just understand the
workings and adjust my expectations accordingly.
ons 12 okt. 2016 kl 10:16 skrev John Souvestre <jo...@souvestre.com
>:
I looked at pi/goal. It uses a sync/atomic CAS. Thus, yes, it provides a
memory barrier.
As someone else already recommended, the call to Gosched() for each loop will
probably tie up the runtime quite a bit. It would probably be better to drop
it entirely (if the spin isn’t going to last long, worst case) or only do it
every so often (perhaps 1,000 or more loops).
Depending on the amount of congestion and what your latency goal is, you might
find that a regular sync/Mutex does as well or better. The fast path (when
there’s little congestion) isn’t much more than a CAS.
John
John Souvestre - New Orleans LA
From: Henrik Johansson [mailto:dahan...@gmail.com ]
Sent: 2016 October 12, Wed 03:02
To: John Souvestre; golang-nuts
Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java
equivalent, program spends most of time in sync.(*Mutex).Lock() and
sync.(*Mutex).Unlock()
Sure that's my question. Does a SpinLock as given in several examples above
provide the same semantics as a proper mutex?
On Wed, Oct 12, 2016, 09:50 John Souvestre <jo...@souvestre.com >
wrote:
Ø … state that one measly atomic load has the same memory effects as a
sync/lock which seems like it might work on some platforms (maybe) but surely
not for all?
I believe that any of the atomic operations in sync/atomic is a memory barrier,
just as a mutex is, and this is for all platforms.
Ø Don't I at least have to load the shared vars using atomic load
(atomic.Value for example) or something similar?
Not if everyone accessing them is using a mutex to synchronize the access.
John
John Souvestre - New Orleans LA
From: golan...@googlegroups.com
[mailto:golan...@googlegroups.com ] On Behalf Of Henrik Johansson
Sent: 2016 October 12, Wed 00:02
To: hiatt@gmail.com ; golang-nuts
Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java
equivalent, program spends most of time in sync.(*Mutex).Lock() and
sync.(*Mutex).Unlock()
Yes I get that but it seems as there other constraints at play here wrt the
memory model.
In essence the spin locks (unless described outside their code somewhere) state
that one measly atomic load has the same memory effects as a sync/lock which
seems like it might work on some platforms (maybe) but surely not for all?
Don't I at least have to load the shared vars using atomic load (atomic.Value
for example) or something similar?
My point is that the protected section isn't guaranteed the same memory rules
as when protected by a standard lock.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts...@googlegroups.c
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
Interesting. I didn’t realize that thread was live again. I thought that this one put it to rest. https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ I don’t know for sure, but I imagine that Russ’ statement about atomics was mainly concerning synchronization – which Go’s sync/atomic operations provide. And I would certainly agree. John John Souvestre - New Orleans LA From: Henrik Johansson [mailto:dahankz...@gmail.com] Sent: 2016 October 12, Wed 07:01 To: John Souvestre; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() I mean <https://github.com/golang/go/issues/5045> https://github.com/golang/go/issues/5045 ons 12 okt. 2016 kl 13:50 skrev John Souvestre <j...@souvestre.com>: Ø I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I’m not sure what thread you are referring to. In general it is best to avoid the sync/atomic stuff unless you * really * need it for performance and you take the time to understand it well. A mutex lock would not prevent another goroutine from doing an atomic operation, for example. So mixing the two could be disastrous. But there are some cases where it can be done. John John Souvestre - New Orleans LA From: Henrik Johansson [mailto:dahankz...@gmail.com] Sent: 2016 October 12, Wed 06:12 To: John Souvestre; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I am not going to use spin locks left and right but just understand the workings and adjust my expectations accordingly. ons 12 okt. 2016 kl 10:16 skrev John Souvestre <j...@souvestre.com>: I looked at pi/goal. It uses a sync/atomic CAS. Thus, yes, it provides a memory barrier. As someone else already recommended, the call to Gosched() for each loop will probably tie up the runtime quite a bit. It would probably be better to drop it entirely (if the spin isn’t going to last long, worst case) or only do it every so often (perhaps 1,000 or more loops). Depending on the amount of congestion and what your latency goal is, you might find that a regular sync/Mutex does as well or better. The fast path (when there’s little congestion) isn’t much more than a CAS. John John Souvestre - New Orleans LA From: Henrik Johansson [mailto:dahankz...@gmail.com] Sent: 2016 October 12, Wed 03:02 To: John Souvestre; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Sure that's my question. Does a SpinLock as given in several examples above provide the same semantics as a proper mutex? On Wed, Oct 12, 2016, 09:50 John Souvestre <j...@souvestre.com> wrote: Ø … state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? I believe that any of the atomic operations in sync/atomic is a memory barrier, just as a mutex is, and this is for all platforms. Ø Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? Not if everyone accessing them is using a mutex to synchronize the access. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Henrik Johansson Sent: 2016 October 12, Wed 00:02 To: hiatt.dus...@gmail.com; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Yes I get that but it seems as there other constraints at play here wrt the memory model. In essence the spin locks (unless described outside their code somewhere) state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? My point is that the protected section isn't guaranteed the same memory rules as when protected by a standard lock. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to gola
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
Ø I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I’m not sure what thread you are referring to. In general it is best to avoid the sync/atomic stuff unless you * really * need it for performance and you take the time to understand it well. A mutex lock would not prevent another goroutine from doing an atomic operation, for example. So mixing the two could be disastrous. But there are some cases where it can be done. John John Souvestre - New Orleans LA From: Henrik Johansson [mailto:dahankz...@gmail.com] Sent: 2016 October 12, Wed 06:12 To: John Souvestre; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I am not going to use spin locks left and right but just understand the workings and adjust my expectations accordingly. ons 12 okt. 2016 kl 10:16 skrev John Souvestre <j...@souvestre.com>: I looked at pi/goal. It uses a sync/atomic CAS. Thus, yes, it provides a memory barrier. As someone else already recommended, the call to Gosched() for each loop will probably tie up the runtime quite a bit. It would probably be better to drop it entirely (if the spin isn’t going to last long, worst case) or only do it every so often (perhaps 1,000 or more loops). Depending on the amount of congestion and what your latency goal is, you might find that a regular sync/Mutex does as well or better. The fast path (when there’s little congestion) isn’t much more than a CAS. John John Souvestre - New Orleans LA From: Henrik Johansson [mailto:dahankz...@gmail.com] Sent: 2016 October 12, Wed 03:02 To: John Souvestre; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Sure that's my question. Does a SpinLock as given in several examples above provide the same semantics as a proper mutex? On Wed, Oct 12, 2016, 09:50 John Souvestre <j...@souvestre.com> wrote: Ø … state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? I believe that any of the atomic operations in sync/atomic is a memory barrier, just as a mutex is, and this is for all platforms. Ø Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? Not if everyone accessing them is using a mutex to synchronize the access. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Henrik Johansson Sent: 2016 October 12, Wed 00:02 To: hiatt.dus...@gmail.com; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Yes I get that but it seems as there other constraints at play here wrt the memory model. In essence the spin locks (unless described outside their code somewhere) state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? My point is that the protected section isn't guaranteed the same memory rules as when protected by a standard lock. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
I looked at pi/goal. It uses a sync/atomic CAS. Thus, yes, it provides a
memory barrier.
As someone else already recommended, the call to Gosched() for each loop will
probably tie up the runtime quite a bit. It would probably be better to drop
it entirely (if the spin isn’t going to last long, worst case) or only do it
every so often (perhaps 1,000 or more loops).
Depending on the amount of congestion and what your latency goal is, you might
find that a regular sync/Mutex does as well or better. The fast path (when
there’s little congestion) isn’t much more than a CAS.
John
John Souvestre - New Orleans LA
From: Henrik Johansson [mailto:dahankz...@gmail.com]
Sent: 2016 October 12, Wed 03:02
To: John Souvestre; golang-nuts
Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java
equivalent, program spends most of time in sync.(*Mutex).Lock() and
sync.(*Mutex).Unlock()
Sure that's my question. Does a SpinLock as given in several examples above
provide the same semantics as a proper mutex?
On Wed, Oct 12, 2016, 09:50 John Souvestre <j...@souvestre.com> wrote:
Ø … state that one measly atomic load has the same memory effects as a
sync/lock which seems like it might work on some platforms (maybe) but surely
not for all?
I believe that any of the atomic operations in sync/atomic is a memory barrier,
just as a mutex is, and this is for all platforms.
Ø Don't I at least have to load the shared vars using atomic load
(atomic.Value for example) or something similar?
Not if everyone accessing them is using a mutex to synchronize the access.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Henrik Johansson
Sent: 2016 October 12, Wed 00:02
To: hiatt.dus...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java
equivalent, program spends most of time in sync.(*Mutex).Lock() and
sync.(*Mutex).Unlock()
Yes I get that but it seems as there other constraints at play here wrt the
memory model.
In essence the spin locks (unless described outside their code somewhere) state
that one measly atomic load has the same memory effects as a sync/lock which
seems like it might work on some platforms (maybe) but surely not for all?
Don't I at least have to load the shared vars using atomic load (atomic.Value
for example) or something similar?
My point is that the protected section isn't guaranteed the same memory rules
as when protected by a standard lock.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
Ø … state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? I believe that any of the atomic operations in sync/atomic is a memory barrier, just as a mutex is, and this is for all platforms. Ø Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? Not if everyone accessing them is using a mutex to synchronize the access. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Henrik Johansson Sent: 2016 October 12, Wed 00:02 To: hiatt.dus...@gmail.com; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Yes I get that but it seems as there other constraints at play here wrt the memory model. In essence the spin locks (unless described outside their code somewhere) state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? My point is that the protected section isn't guaranteed the same memory rules as when protected by a standard lock. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()
As I understand it, Go’s mutex lock will spin for a while (good if everyone using the mutex holds it for only very short periods), but will back off to a less compute intensive method after a while. This avoids tying up a CPU at the cost of some latency in seeing the other guy’s unlock. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of sphilip...@gmail.com Sent: 2016 October 04, Tue 04:10 To: golang-nuts Subject: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Try spinlocks instead of mutexes: https://github.com/pi/goal/blob/master/gut/spinlock.go -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] infinite loop makes program stuck
I see that others have already addressed the locking issued, but I noticed
something else. I don’t understand why you are using “select”. With only one
case, I think that it’s normally going to fail and exit the select block, then
loop due to the “for”. This will make it run constantly.
If you get rid of the “select” then the loop will block until something comes
in from the channel.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of liminglang...@gmail.com
Sent: 2016 October 11, Tue 21:26
To: golang-nuts
Subject: [go-nuts] infinite loop makes program stuck
Hi, there. I've read the FAQ and specifically the concurrency part. Tell me if
the problem has been discussed anywhere.
I used an infinite loop to block a goroutine until a value is big enough:
for commitIndex < index {}
I know its bad but its just a very intuitive and fast to implement. And I
incremented commitIndex in another goroutine monotonically:
for {
select {
case <-ch:
mu.Lock()
commitIndex++
mu.Unlock()
}
}
These are the only two places that access commitIndex. I didn't acquire the
lock when reading commitIndex since I think its OK to read a stale value in my
case. The program is a complex Raft replicated server so there're many other
goroutines. The problem is the program became stuck after running for a while.
commitIndex stopped updating and even the Raft servers stopped communicating
with each other. I ended up adding a Sleep() in the for loop and everything
worked. Is this normal? Or there's a problem with the goroutine scheduling?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: Just because we can add multiple logical processors for the scheduler to use doesn’t mean we should
Ø But A GOMAXPROCS value larger than NumberAvaliableCpuCores will always decrease the performance, IMO. Although unusual, I did have a case where it was handy to use double the value of CPUs. It was a situation where there were a number of low-priority, compute-bound processes and a bunch of regular processes. The regular processes saw less latency due to the operating system being able to implement its form of fairness when preemptively scheduling the treads/procs. Btw – If you were referring to runtime.NumCPU it’s actually the number of logical CPUs, not cores. Quite often hyperthreading results in more CPUs than cores. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of T L Sent: 2016 September 24, Sat 04:22 To: golang-nuts Subject: [go-nuts] Re: Just because we can add multiple logical processors for the scheduler to use doesn’t mean we should Usually, GOMAXPROCS==NumberAvaliableCpuCores (the default value since go1.5) will get the best performance. For some special cases, a smaller GOMAXPROCS value will perform better. But A GOMAXPROCS value larger than NumberAvaliableCpuCores will always decrease the performance, IMO. On Friday, September 23, 2016 at 5:56:11 PM UTC+8, WALID BELRHALMIA wrote: Hello my golang brother, i was reading William kennedy post about Concurency https://www.goinggo.net/2014/01/concurrency-goroutines-and-gomaxprocs.html and at the end he said "Just because we can add multiple logical processors for the scheduler to use doesn’t mean we should" , because i think that ading the max logical CPU to awer program can only add moe performance, can somme one provide me with more information. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Having difficulty testing this "cleanly"
OK. Give me a minute to add that. I just wanted to make sure I was headed in
the right direction. J
Note: In looking at your original code I didn’t see any way that the error
could happen, so I ignored that case. Given this, there was no need for the
h.closed channel.
Back in a few. J
John
John Souvestre - New Orleans LA
From: Evan Digby [mailto:evandi...@gmail.com]
Sent: 2016 September 13, Tue 15:59
To: John Souvestre; golang-nuts
Subject: Re: [go-nuts] Having difficulty testing this "cleanly"
Hi John,
What you've posted is a valid way to implement the handler, but not a way to
validate it.
The implementation in the example isn't the problem. It's how to validate the
implementation with a test.
If we add a WaitGroup.Wait inside the handler then the test is not valid
because it will wait until they're done. If the test does the waiting, then we
aren't validating that the implementation itself does the waiting.
I'm trying to find a clean way to validate that the waiting is done by the
Close call.
Thanks again for your effort in this!
Evan
On Tue, 13 Sep 2016 at 13:52 John Souvestre <j...@souvestre.com> wrote:
Hi Evan.
I still don’t quite understand exactly what you are shooting for. I tried to
reimplement what you posted originally. Check out
https://play.golang.org/p/koUJYCKFpa. Does this come close functionally?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Evan Digby
Sent: 2016 September 13, Tue 15:32
To: golang-nuts
Cc: aro...@gmail.com
Subject: Re: [go-nuts] Having difficulty testing this "cleanly"
Hi John/Egon/Augusto,
I should point out is that all we need to guarantee (barring abnormal
termination of course) is that once a task starts processing, it finishes.
Partially processed messages are bad, but http requests that don't result in a
message being processed at all are okay.
We don't need to guarantee that the result of every Accept in the HTTP server
results in a processed message. We handle this on the OPS side by ensuring we
stop sending requests to that instance before terminating the process. We just
want to make sure, at that point, that the messages which did make it to the
handler are flushed.
So the case where:
h.Handle(...) <-- gets past the closed channel check, calls go ..., butthe
goroutine doesn't execute yet.
h.Close() <-- closes the close channel, Locks and Unlocks,returns.
...now the goroutine executes and acquires the read lock.
We actually don't care if "Handle" completes in this example. We only care if
that our task handler starts processing a message that it completes the
processing.
Thanks again,
Evan
On Tuesday, 13 September 2016 13:24:03 UTC-7, aro...@gmail.com wrote:
The mutex approach is fundamentally broken because you can't guarantee that the
tasks are all started (and have a read-lock acquired) before you call close.
Consider:
h.Handle(...) <-- gets past the closed channel check, calls go ..., butthe
goroutine doesn't execute yet.
h.Close() <-- closes the close channel, Locks and Unlocks,returns.
...now the goroutine executes and acquires the read lock.
So really, if you can't control the Handle() function, you need two WaitGroups:
one to verify that all goroutines have started before shutting down the task
handler and a second one for all goroutines to have finished. However, it's
tricky if we don't know the real use case.
Sounds like you are trying to do graceful http shutdown. Have you looked at
other libraries that do that? If you don't have a way to account for the time
between Handle(..) is called and the goroutine starts, you always might miss a
task that got called near the time Close() was called.
- Augusto
On Tuesday, September 13, 2016 at 12:50:50 PM UTC-7, Evan Digby wrote:
Hi Aroman,
Your approach using the WaitGroup is definitely better in this toy example. The
reason I didn't use the WaitGroup is because the non-toy example is wrapping
the HTTP Server handler. I have no way to inject an "add" before the goroutine
is created since that's handled by Go's HTTP Server without re-implementing the
accept->handle loop using the listener.
Apologies for not giving the full context in the example.
I'm not sure how it could block an outstanding task since the closed channel is
called before the Lock(), so no additional calls to RLock will be made at that
point, and the Lock will just wait until all of the RLocks are complete.
Regarding your testing strategy, I do like it better than any of my current
strategy; however, There still is a chance that a task could complete between
lines 90 and 91:
h.Close()
events <- ALL_TASKS_FINISHED
So this doesn't solve the racy-ness I'm concerned about unless you pu
RE: [go-nuts] Having difficulty testing this "cleanly"
Ø The RW mutex is used by the implementation to guarantee that all handlers are complete before we return from "Close", which is what I'm attempting to test. I’m not sure that the mutex is going to work like you want. There’s no guarantee that the h.RLock() in the goroutine will execute in a timely fashion. I think that you’d have to call it before the goroutine. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 14:59 To: golang-nuts Subject: Re: [go-nuts] Having difficulty testing this "cleanly" Hi John, Consider the "main" function a test, and not a sane usage of the handler. The multiple sync methods in "main" are trying to accomplish: 1) Ensure all tasks have started (allStarted waitgroup) 2) Wait until we're ready to call "Done" before we proceed with the task (timeToFinish channel block) These synchronizations wouldn't exist in actual usage. They're just test setup. The RW mutex is used by the implementation to guarantee that all handlers are complete before we return from "Close", which is what I'm attempting to test. Thanks again! On Tuesday, 13 September 2016 12:49:07 UTC-7, John Souvestre wrote: Hi Evan. I looked at the code you posted. I’m having a problem seeing exactly what you are trying to do. Also, it appears to be using multiple synchronization techniques: Mutex, WaitGroup, and 2 blocking channels. Am I correct in guessing that you want to know how long it took to get all of the tasks running? Then you want to wait till all of the tasks are complete? If so, I’m thinking that using 2 WaitGroups would do the job – one to show when all the tasks are running and one to show when all the tasks are done. No mutex and no blocking channels. John John Souvestre - New Orleans LA From: golan...@googlegroups.com [mailto:golan...@googlegroups.com ] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 14:19 To: golang-nuts Subject: Re: [go-nuts] Having difficulty testing this "cleanly" Hi John, Thanks for the reply. I've tried many incarnations that include WaitGroups; however, none seem to achieve the desired result. If I add a WaitGroup with a defer done in the handler, and then wait after the Close() then the test itself implements the requirement and won't protect from future refactors. There's no way to test that a WaitGroup is done without waiting for it, and even if there was it would be racy because between the Close() and WaitGroup wait call tasks could complete. If I wrapped the wait and the done in goroutines to see which one happened first, also racy. If you have something else in mind can you elaborate on how it would help in this case? Thanks again! Evan On Tuesday, 13 September 2016 12:01:29 UTC-7, John Souvestre wrote: Have you considered using a sync.WaitGroup? John John Souvestre - New Orleans LA From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 13:56 To: golang-nuts Subject: [go-nuts] Having difficulty testing this "cleanly" Has anyone come across a good way, non-racy way to ensure that N tasks are guaranteed to be completed after a function is called? Essentially I have a “Close” function that must be guaranteed to block until all tasks are finished. Achieving this was pretty simple: wrap each task in an RLock, and then a Lock on close. Example: https://play.golang.org/p/7lhBPUhkUE Now I want to write a solid test to guarantee Close will meet that requirement of all tasks must finish first for posterity. In that example, try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no longer outputs many, if any, lines. I'm trying to prevent that from happening in the future by some cowboy refactor! All of the ways I can come up with involve Sleeping or launching more tasks than I _think_ can be finished in time--obviously not good! I feel like I must be missing some obvious way to test this and I'll end up feeling silly once someone replies with the solution. I'm okay with that! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups
RE: [go-nuts] Having difficulty testing this "cleanly"
Hi again. Ø There's no way to test that a WaitGroup is done without waiting for it, and even if there was it would be racy because between the Close() and WaitGroup wait call tasks could complete. If you don’t mind being blocked, then Wait is just what you want. Since it’s occurring in the same function (main) that the Add is taking place earlier, there is no race. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 14:19 To: golang-nuts Subject: Re: [go-nuts] Having difficulty testing this "cleanly" Hi John, Thanks for the reply. I've tried many incarnations that include WaitGroups; however, none seem to achieve the desired result. If I add a WaitGroup with a defer done in the handler, and then wait after the Close() then the test itself implements the requirement and won't protect from future refactors. There's no way to test that a WaitGroup is done without waiting for it, and even if there was it would be racy because between the Close() and WaitGroup wait call tasks could complete. If I wrapped the wait and the done in goroutines to see which one happened first, also racy. If you have something else in mind can you elaborate on how it would help in this case? Thanks again! Evan On Tuesday, 13 September 2016 12:01:29 UTC-7, John Souvestre wrote: Have you considered using a sync.WaitGroup? John John Souvestre - New Orleans LA From: golan...@googlegroups.com [mailto:golan...@googlegroups.com ] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 13:56 To: golang-nuts Subject: [go-nuts] Having difficulty testing this "cleanly" Has anyone come across a good way, non-racy way to ensure that N tasks are guaranteed to be completed after a function is called? Essentially I have a “Close” function that must be guaranteed to block until all tasks are finished. Achieving this was pretty simple: wrap each task in an RLock, and then a Lock on close. Example: https://play.golang.org/p/7lhBPUhkUE Now I want to write a solid test to guarantee Close will meet that requirement of all tasks must finish first for posterity. In that example, try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no longer outputs many, if any, lines. I'm trying to prevent that from happening in the future by some cowboy refactor! All of the ways I can come up with involve Sleeping or launching more tasks than I _think_ can be finished in time--obviously not good! I feel like I must be missing some obvious way to test this and I'll end up feeling silly once someone replies with the solution. I'm okay with that! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Having difficulty testing this "cleanly"
Hi Evan. I looked at the code you posted. I’m having a problem seeing exactly what you are trying to do. Also, it appears to be using multiple synchronization techniques: Mutex, WaitGroup, and 2 blocking channels. Am I correct in guessing that you want to know how long it took to get all of the tasks running? Then you want to wait till all of the tasks are complete? If so, I’m thinking that using 2 WaitGroups would do the job – one to show when all the tasks are running and one to show when all the tasks are done. No mutex and no blocking channels. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 14:19 To: golang-nuts Subject: Re: [go-nuts] Having difficulty testing this "cleanly" Hi John, Thanks for the reply. I've tried many incarnations that include WaitGroups; however, none seem to achieve the desired result. If I add a WaitGroup with a defer done in the handler, and then wait after the Close() then the test itself implements the requirement and won't protect from future refactors. There's no way to test that a WaitGroup is done without waiting for it, and even if there was it would be racy because between the Close() and WaitGroup wait call tasks could complete. If I wrapped the wait and the done in goroutines to see which one happened first, also racy. If you have something else in mind can you elaborate on how it would help in this case? Thanks again! Evan On Tuesday, 13 September 2016 12:01:29 UTC-7, John Souvestre wrote: Have you considered using a sync.WaitGroup? John John Souvestre - New Orleans LA From: golan...@googlegroups.com [mailto:golan...@googlegroups.com ] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 13:56 To: golang-nuts Subject: [go-nuts] Having difficulty testing this "cleanly" Has anyone come across a good way, non-racy way to ensure that N tasks are guaranteed to be completed after a function is called? Essentially I have a “Close” function that must be guaranteed to block until all tasks are finished. Achieving this was pretty simple: wrap each task in an RLock, and then a Lock on close. Example: https://play.golang.org/p/7lhBPUhkUE Now I want to write a solid test to guarantee Close will meet that requirement of all tasks must finish first for posterity. In that example, try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no longer outputs many, if any, lines. I'm trying to prevent that from happening in the future by some cowboy refactor! All of the ways I can come up with involve Sleeping or launching more tasks than I _think_ can be finished in time--obviously not good! I feel like I must be missing some obvious way to test this and I'll end up feeling silly once someone replies with the solution. I'm okay with that! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Having difficulty testing this "cleanly"
Have you considered using a sync.WaitGroup? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Evan Digby Sent: 2016 September 13, Tue 13:56 To: golang-nuts Subject: [go-nuts] Having difficulty testing this "cleanly" Has anyone come across a good way, non-racy way to ensure that N tasks are guaranteed to be completed after a function is called? Essentially I have a “Close” function that must be guaranteed to block until all tasks are finished. Achieving this was pretty simple: wrap each task in an RLock, and then a Lock on close. Example: https://play.golang.org/p/7lhBPUhkUE Now I want to write a solid test to guarantee Close will meet that requirement of all tasks must finish first for posterity. In that example, try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no longer outputs many, if any, lines. I'm trying to prevent that from happening in the future by some cowboy refactor! All of the ways I can come up with involve Sleeping or launching more tasks than I _think_ can be finished in time--obviously not good! I feel like I must be missing some obvious way to test this and I'll end up feeling silly once someone replies with the solution. I'm okay with that! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Assigning +Inf to a float32 ..
Ignore. math.NaN() is there! J
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:j...@souvestre.com]
Sent: 2016 September 11, Sun 02:39
To: 'golang-nuts'
Subject: RE: [go-nuts] Assigning +Inf to a float32 ..
This does beg the question: Why is there no math.NaN() function?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2016 September 11, Sun 01:00
To: golang-nuts
Cc: xiiop...@gmail.com
Subject: Re: [go-nuts] Assigning +Inf to a float32 ..
https://play.golang.org/p/RthMnILvkP
func main() {
inf := float32(math.Inf(+1))
fmt.Println(inf)
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Assigning +Inf to a float32 ..
This does beg the question: Why is there no math.NaN() function?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2016 September 11, Sun 01:00
To: golang-nuts
Cc: xiiop...@gmail.com
Subject: Re: [go-nuts] Assigning +Inf to a float32 ..
https://play.golang.org/p/RthMnILvkP
func main() {
inf := float32(math.Inf(+1))
fmt.Println(inf)
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Fast ConcurrentCounter without memory sharing
Hello Gaurav. You might want to look at Jon Gjengset's project: https://github.com/jonhoo/drwmutex Also, I seem to recall Dmitry saying that sync.Pool distributes locking. So it might be worth looking into. Another type of lock which might be of interest is MCS (or K42, CLH, HCLH). John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Ian Lance Taylor Sent: 2016 August 14, Sun 14:21 To: Gaurav Agarwal Cc: golang-nuts Subject: Re: [go-nuts] Fast ConcurrentCounter without memory sharing On Sun, Aug 14, 2016 at 9:58 AM, Gaurav Agarwal <gauravagarw...@gmail.com> wrote: > Ian, thanks for the explanation and the link ! > > But I am still unclear how to implement such a concurrent counter in Go - > given that we can't find out what thread/cpu is the goroutine executing. > Note that in this case there was never the need of pinning a goroutine to a > thread or cpu; just that we wanted to know which is it, at any given moment > so as to access the required memory location. > > Do you have any alternate ideas for this? I think the last time a similar though not identical concept was discussed was this thread: https://groups.google.com/d/msg/golang-nuts/zt_CQssHw4M/TteNG44geaEJ It would be interesting to know what the potential speedup is. It should be easy enough to write a C program to measure that. But when writing such a program, remember that no real program will simply increment a concurrent counter. The question is not just how much speedup you can get from a concurrent counter, but how much it will matter to a real program. Anyhow, that aside, if you know how many goroutines you are going to run, just allocate a slice with that many elements. If you don't, use a set of fixed size arrays and have each goroutine grab a pointer to a possibly-new array when it starts. Pass down the pointer. If these approaches seem awkward, I suppose you could get syscall(syscall.GETCPU, ...) when you want to increment a counter. But that would admittedly introduce overhead that would distort the results. We do not plan to modify the Go runtime to expose a thread or CPU ID, because although it's true that your application doesn't care much if the value becomes immediately stale, other applications would care. It seems unwise to expose a value that is extremely easy to misuse in a way that will often succeed and occasionally and inexplicably fail. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] What dependency management tool do you use?
> Gb puts emphasis on reliable and reproducible builds; none of the other
package managers have such feature, ...
None? Isn't that the main purpose of a package manager. I see many which seem
to do this in addition to gb, for example: godep, glide, govendor, and gvt.
Perhaps you weren’t aware of them?
John
John Souvestre - New Orleans LA
-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Mauro Toffanin
Sent: 2016 July 15, Fri 04:48
To: golang-nuts@googlegroups.com
Subject: Re: [go-nuts] What dependency management tool do you use?
On 12/07/16 22:23, Henrik Johansson wrote:
> I use gb. I like it a lot and I have had no issues.
+1
Gb puts emphasis on reliable and reproducible builds; none of the other
package managers have such feature, and none of them work so well as gb.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] What dependency management tool do you use?
> You would be surprised to know that gvt uses gb internally,
> and both the projects exchange pieces of code and ideas ;)
That's not the impression I get. I might be wrong, but I believe that gvt
does not share most of gb's philosophy: 1) It is based on just gb-vendor, not
the rest of gb. 2) It uses Go's vendor directory without the top-level (single
project) restriction, and in a manner which is compatible with the go tool (no
vendor/src). 3) It uses the go tool, not the gb replacement tool. 4) It uses,
rather than ignores, GOPATH. 5) It provides some support for versioning.
John
John Souvestre - New Orleans LA
-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Mauro Toffanin
Sent: 2016 July 16, Sat 10:59
To: golang-nuts@googlegroups.com
Subject: Re: [go-nuts] What dependency management tool do you use?
On 16/07/16 15:16, Peter Mogensen wrote:
> * Use gvt for vendoring everything into /vendor
You would be surprised to know that gvt uses gb internally, and both the
projects exchange pieces of code and ideas ;)
> But wrt. to the talk above: Didn't Dave Cheney dismiss the diamond
> problem a little too fast? Sure you "cannot" do that, but you can still
> end up in a situation where you depend on 2 different libraries, each
> which depends on different specific version of the same 3rd package.
I actually agree with Cheney's decision:
http://dave.cheney.net/2015/06/09/gb-a-project-based-build-tool-for-the-go-programming-language
The probability of encountering a diamond dependency conflict is so low
that makes sense to treat it like a corner case and to force the final
user to manually take action; providing some boiler-plate solver will
never guarantee a valid consistent resolution for every single
conflicting case, leading only to an increased complexity� of the tool.
Automatically solving the diamond dependency conflict requires tampering
with the Golang source code anyway, which means we are back to the
square one with dirty work-arounds: with source code tampering you lose
the "reliable" and "reproducible" part of your builds.
One could argue that solving the diamond dependency in an automatic way
has benefits per se. I can understand the allure of that reasoning, but
it's not the Go way of doing things; it's like with Generics: some
people like them and want them, some others don't and prefer to stick to
manual implementation.
There isn't an easy answer to such problems.
�- you have to deal with graph theory, implement Breadth First and Depth
First algorithms, impose barriers and fences all over the PM; I
personally don't see the advantage considering its complexity vs the
little outcome. It's easier, and faster, to manually solve the conflict.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Re: How to make the first character in a string lowercase?
What if the first character is a combined code point? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Viktor Kojouharov Sent: 2016 July 14, Thu 03:57 To: golang-nuts Subject: [go-nuts] Re: How to make the first character in a string lowercase? https://play.golang.org/p/miLAFSDjrS For unicode On Thursday, July 14, 2016 at 7:26:13 AM UTC+3, Tamás Gulácsi wrote: But this works only for ASCII input! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] Go test to run over sub packages?
Ø Symlinks and the go tools should be avoided. Was this done intentionally? If so, why? If not, is it a bug which should be fixed? John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2016 June 21, Tue 19:19 To: golang-nuts Cc: gabriel.kop...@gmail.com Subject: Re: [go-nuts] Go test to run over sub packages? I'm sorry to say that that is bad advice. Symlinks and the go tools should be avoided. On Wednesday, 22 June 2016 08:29:33 UTC+10, gabriel...@gmail.com wrote: Hi Ian, thanks for the confirmation! It turns out that the cause of this behavior is that I had followed the instructions at https://github.com/karlseguin/the-little-go-book/blob/9f95b4405760fe9d24d4f9b7da93889cc9306f58/en/go.md#getting-started and symlinked thus: `$ ln -s ~/code/golang-workspace/src/github.com/foo/proj ~/code/proj` In a directory structure without the symlink, things work correctly :) I'll file an issue on the Little Book of Go about this gotcha. Gabe On Tuesday, June 21, 2016 at 3:09:35 PM UTC-7, Ian Lance Taylor wrote: On Tue, Jun 21, 2016 at 12:42 PM, <gabriel...@gmail.com> wrote: > Is `$ go test github.com/foo/proj/...` <http://github.com/foo/proj/...> > really supposed to work? Yes. > When I run it I get > > warning: "github.com/foo/proj/.. <http://github.com/foo/> ." matched no > packages > no packages to test > > But `cd src/github.com/foo/proj && go test ./...` does work as suggested. What is the value of your GOPATH environment variable? Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [go-nuts] How to properly get basename under DOS?
> Package path is for *nix paths only. import "path/filepath" instead.
When should path be used? Or should it be deprecated in favor of path/filepath?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Jan Mercl
Sent: 2016 June 14, Tue 12:01
To: Tong Sun; golang-nuts
Subject: Re: [go-nuts] How to properly get basename under DOS?
Package path is for *nix paths only. import "path/filepath" instead.
On Tue, Jun 14, 2016, 18:55 Tong Sun <suntong...@gmail.com> wrote:
I thought to get basename, we should use the official path.Base --
https://golang.org/pkg/path/#Base
However, I just found out that it is not working under DOS --
https://play.golang.org/p/kfr0N50JWc
package main
import (
"fmt"
"path"
)
func main() {
fmt.Println(path.Base("/a/b.c"))
fmt.Println(path.Base(`C:\Program Files\Microsoft Visual Studio
9\Common7\IDE\devenv.exe`))
}
The output is:
b.c
C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\devenv.exe
What's your solution for this, that is working for both Linux and Windows?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
