Re: [go-nuts] Re: go get: You are not currently on a branch

[Jan Mercl]

On Thu, Oct 13, 2016 at 3:59 AM Tong Sun  wrote:

> You can blame git, but I think "go get" can do better to avoid the
problem in the first place.

'go get' just executes `git clone` or `git pull`. What would you suggest
'go get' can do to "do better"?

-- 

-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] infinite loop makes program stuck

[Matt Harden]

On Wed, Oct 12, 2016 at 1:33 AM Minglangjun Li 
wrote:

> On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis 
>  wrote:
>
> If you have multiple CPUs (and the Go memory model assumes that you
> always can) they won't even write updated values from their cache out
> to main memory until they hit a lock.
> The reading CPU has read a value from main memory and put it in it's
> cache, it assumes that value won't change in main memory unless it
> hits a lock of it's own.
>
> If you don't lock then both CPUs will just sit in their own little
> world updating and reading values in their own caches and are never
> aware of each other.
>
>
> Thanks Jesse. Good to know that.
>
> On Wed, Oct 12, 2016 at 3:26 PM, John Souvestre 
>  wrote:
>
> 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.
>
>
That's not true. One of the select cases has to be satisfied; there is no
failure. If there were a default case, that would be selected if no other
case is ready. Without a default case, the select will block until one of
the cases is ready. A single-case select can be replaced with a single send
statement or receiving into a variable.


> 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
>
>
> Please forgive me for that. I haven't been familiar with 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.

[go-nuts] Re: Survey - do you use Go in the cloud?

['Andrew Jessup' via golang-nuts]

Hi Ondrej, thanks for the feedback!

While the intent of this particular survey was to understand what kind of 
workloads go customers were running on various cloud providers, we're also 
taking a close look at previous surveys that have looked at vendoring and 
packaging preferences, as well as the direction the community is leaning 
towards as we improve the developer workflow on Cloud Platform. 

We hear you that many folks have their own tools and strategies for solving 
this and would prefer to see their workflows supported rather than have 
something forced on them. That's generally what we strive to support.

On Wednesday, 12 October 2016 04:09:14 UTC-7, Ondrej wrote:
>
> Andrew,
> Thanks for doing this. The Cloud Platform is great and I'm glad you're 
> looking into this. Here are my 2c that didn't quite fit in the survey: when 
> not running in a 'full' environment (lambdas/cloud functions, app engine, 
> containers etc.), it would be good to keep the package/vendoring conundrums 
> in mind, especially now as it's quite a live discussion as to what the best 
> design of it should be. E.g. last time I tried Heroku, it forced me to use 
> Godep, which was a bit annoying and I ended up dropping Heroku as an 
> option, because I didn't want to change my workflows just for one 
> environment.
>
> Thanks!
>
> On Tuesday, 11 October 2016 21:49:30 UTC+1, Andrew Jessup wrote:
>>
>> Hi Gophers,
>>
>> I'm on the Cloud Platform group at Google. We're trying to understand 
>> what kinds of services Go developers are building that they plan to host 
>> with a third party provider (any provider, not just Google) and why they 
>> picked Go for doing so. 
>>
>> As such we're putting up a short (no, really - it's only 4 questions) 
>> survey. 
>>
>> The survey is here - https://goo.gl/forms/XH5oXX106S7u7CMg2
>>
>> If you're building something to run in the cloud using Go, we'd love to 
>> hear from you. We'll publish the (anonymized) results of this survey back 
>> to this list for anyone else who is interested.
>>
>> Cheers,
>>
>> Andrew
>>
>

-- 
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 get: You are not currently on a branch

[Thomas Modeneis]

Hi Oir,
The main problem seems to be related to go get believe me or not.
I manage to get this right after I deleted  $GOPATH/pkg/* 
and  $GOPATH/src/golang.org

Thanks


On Wednesday, October 12, 2016 at 3:51:07 PM UTC+2, ohir wrote:
>
> Dnia 2016-10-12, o godz. 02:37:16 
> Thomas Modeneis  napisał(a): 
>
> > You are not currently on a branch. Please specify which 
> > branch you want to merge with. See git-pull(1) for details. 
>
> This is common to freshmen to get a checkout of some tag then 
> forget they did it. This is a root cause of update fails. 
>
> > Oh this is one of the problems that is really time consuming. I'm not 
> sure 
> > if this is related, but I've never had this kind of problems before 
> +1.7. 
>
> Do you use any half-baked 'pkg versioning' tool? 
> If you did not checked by hand, such tool may be a culprit. 
>
> > Any ideas ? 
>
> Better education? 
>
> OK. Go get docs should have a warning box in red flash: 
>
> [ Either learn about git usage or never ever tinker within 
>  $GOPATH/src/github.com. If go get -u barks on you with 'You are 
> not currently on a branch' message, cd into the mentioned directory and 
> do: 
> 'git checkout master' there. After that you may do 'go get -u' again. 
> Rinse 
> and repeat. ] 
>
>
> -- 
> Wojciech S. Czarnecki 
>^oo^ OHIR-RIPE 
>

-- 
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()

[John Souvestre]

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  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()

[Henrik Johansson]

Thanks for clarifying that Ian!

On Wed, Oct 12, 2016, 19:21 Ian Lance Taylor  wrote:

> On Wed, Oct 12, 2016 at 9:39 AM, Konstantin Khomoutov
>  wrote:
> > On Wed, 12 Oct 2016 07:36:15 -0500
> > John Souvestre  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?
>
>
> I think I've lost the context here, but: 1) I agree that sync/atomic
> should ideally have more details in the memory model
> (https://golang.org/issue/5045); 2) atomic.LoadXX is either a full
> barrier or a load-acquire, and atomic.StoreXX is either a full barrier
> or a store-release.  EIther way, goroutine 2 will see the value
> assigned to data in goroutine 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] Function pointer vs interface for callback?

[Shaun Crampton]

Thanks for the tips.

On Wed, Oct 12, 2016 at 2:11 PM Jesse McNelis  wrote:

> On Wed, Oct 12, 2016 at 11:05 PM,   wrote:
> >  Seems like a function
> > pointer is more universal (I don't even need an object to be a receiver)
> but
> > maybe an interface is more idiomatic?
>
> An interesting pattern from the http pkg is that a function type can
> also implement an interface.
> https://golang.org/pkg/net/http/#HandlerFunc
>

-- 
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] Re: About panic/recover in Golang

[digg]

On Thursday, October 13, 2016 at 12:31:35 AM UTC+8, di...@veryhaha.com 
wrote:
>
> I don't like the spec docs for panic/recover in Golang, for the spec docs 
> is vague and not clear on when recover will take effect.
>
> So I wrote some examples to get the mechanism of panic/recover in Golang.
>
> // example A
> func main() {
> defer func() {
> fmt.Println(recover())
> }()
> panic(1) // recovered
> }
>
> = result:
> 1
>
>
>
> // example B
> func main() {
> defer func() {
> defer func() {
> fmt.Println(recover())
> }()
> 
> panic(2) // recovered
> }()
> panic(1) // not recover
> }
>
> = result:
> 2
> panic: 1
>
>
>
> // example c
> func main() {
> defer func() {
> defer func() {
> recover()
> panic(3)
> }()
> panic(2)
> }()
> panic(1) 
> }
>
> = result:
> 2
> panic: 1
> panic: 2 [recovered]
> panic: 3
>
>
>
>
> // example D
> func main() {
> defer func() {
> recover()
> }()
> defer func() {
> panic(2) // recovered, (overwrite 1)
> }()
> defer func() {
> panic(1) // recovered, (overwritten by 2)
> }()
> }
>
> = result:
> 2
>
>
>
> // example E
> func main() {
> defer func() {
> defer func() {
> fmt.Println(recover())
> }()
> }()
> panic(1) // not recover
> }
>
> = result:
> 
> panic: 1
>
>
>
> // example F
> func main() {
> defer func() {
> func() {
> fmt.Println(recover())
> }()
> }()
> panic(1) // not recover
> }
>
> = result (same as last one):
> 
> panic: 1
>
>
>
>
> // example G
> func main() {
> defer fmt.Println(recover())
> panic(1) // not recover
> }
>
> = result:
> 
> panic: 1
>
>
> // example H
> func main() {
> defer func() {
> fmt.Println(recover())
> }()
> 
> func() {
> func() {
> panic(1) // recovered
> }()
> }()
> }
>
> = result:
> 1
>
>
> So, it looks the calling of recover only takes effect only when both of 
> the following two conditions are met:
> 1. the caller of calling recover must be a deferred function calling .
> 2. the panic must happened in (may not originate from) the caller function 
> of caller of calling recover.
>
> Where or not the calling of recover is deferred or not is not important.
>

sorry, typo here, it should be "whether" instead of "where".

>
> Is the conclusion right?
>

-- 
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()

[Ian Lance Taylor]

On Wed, Oct 12, 2016 at 9:39 AM, Konstantin Khomoutov
 wrote:
> On Wed, 12 Oct 2016 07:36:15 -0500
> John Souvestre  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?


I think I've lost the context here, but: 1) I agree that sync/atomic
should ideally have more details in the memory model
(https://golang.org/issue/5045); 2) atomic.LoadXX is either a full
barrier or a load-acquire, and atomic.StoreXX is either a full barrier
or a store-release.  EIther way, goroutine 2 will see the value
assigned to data in goroutine 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.

Re: [go-nuts] Re: Suggestions for parsing Forwarded HTTP Header (RFC 7239)

[Jonathan Yu]

On Tue, Oct 11, 2016 at 10:08 PM, Tim Heckman  wrote:

> Hi Gophers!
>
> I ended up implementing a package for parsing the header. It didn't seem
> like there was anything else purpose-built for it:
>
> * https://github.com/theckman/httpforwarded
>

The Gorilla Framework has middleware for handling this header:
http://www.gorillatoolkit.org/pkg/handlers#ProxyHeaders

I wonder if it can be switched to use your library?  I like the idea of
reusing common functionality like this.

>
> Any feedback on the code, or the project in general, is welcome.
>
> Cheers!
> -Tim
>
> On Saturday, October 8, 2016 at 12:17:27 PM UTC-7, Tim Heckman wrote:
>>
>> Hey Gophers!
>>
>> I'm working on a small project where I'm looking to support the
>> "Forwarded" header as defined in RFC-7239[1]. For those unfamiliar, it's a
>> standardization and unification of the "X-Forwarded-For" and
>> "X-Forwarded-Proto" headers, among others. The simplest version of the
>> header looks like the following:
>>
>> Forwarded: for=192.0.2.1; by=192.0.2.2; proto=http
>>
>> My initial (naïve) thought was that I could use the
>> mime.ParseMediaType()[2] function to parse the value of the header. This
>> results in an error because that function is only designed to parse things
>> like the "Content-Disposition" header (i.e., things that have a media-type
>> before the key=value parameters).
>>
>> Reading RFC-7239 further, it becomes quite apparent that more complex
>> header values are possible. You can not only have multiple Forwarded
>> headers, but you can also have multiples of the key=value parameters within
>> a single header-value. This means even the parameter parsing code of the
>> mime.ParseMediaType() function isn't compatible if the request has the
>> following (notice the comma in line 2):
>>
>> Forwarded: for=192.0.2.42; proto=http
>> Forwarded: for=192.0.2.1, for=64.72.88.33
>>
>> At the time of writing, RFC-7239 is in the Proposed Standard status
>> (meaning it's ripe for implementation support). I've been doing some
>> digging, and it doesn't seem like the stdlib of Go is capable of parsing
>> this header in a meaningful way. Likewise, it doesn't look like anyone has
>> tackled parsing this header as a third-party package.
>>
>> I wouldn't want to duplicate effort, so does anyone know if someone has
>> built a package for parsing this header?
>> Do you think it's a good idea to open an issue on the Go project to
>> inquire about implementing a parser, in the "mime" package, that's capable
>> of extracting the parameters from all "Forwarded" header values of a
>> request? Is this a better fit for a third-party package?
>>
>> Cheers!
>> -Tim
>>
>> [1] https://tools.ietf.org/html/rfc7239
>> [2] https://golang.org/pkg/mime/#ParseMediaType
>>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

-- 
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] About panic/recover in Golang

[Konstantin Khomoutov]

On Wed, 12 Oct 2016 09:21:07 -0700 (PDT)
d...@veryhaha.com wrote:

> I don't like the spec docs for panic/recover in Golang, for the spec
> docs is vague and not clear on when recover will take effect.
[...]
> So, it looks the calling of recover only takes effect only when both
> of the following two conditions are met:
> 1. the caller of calling recover must be a deferred function calling .
> 2. the panic must happened in (may not originate from) the caller
> function of caller of calling recover.
[...]

Not to answer your question directly, but does [1] helps in
understanding this part of the language?

1. https://blog.golang.org/defer-panic-and-recover

-- 
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] About panic/recover in Golang

[digg]

I don't like the spec docs for panic/recover in Golang, for the spec docs 
is vague and not clear on when recover will take effect.

So I wrote some examples to get the mechanism of panic/recover in Golang.

// example A
func main() {
defer func() {
fmt.Println(recover())
}()
panic(1) // recovered
}

= result:
1



// example B
func main() {
defer func() {
defer func() {
fmt.Println(recover())
}()

panic(2) // recovered
}()
panic(1) // not recover
}

= result:
2
panic: 1



// example c
func main() {
defer func() {
defer func() {
recover()
panic(3)
}()
panic(2)
}()
panic(1) 
}

= result:
2
panic: 1
panic: 2 [recovered]
panic: 3




// example D
func main() {
defer func() {
recover()
}()
defer func() {
panic(2) // recovered, (overwrite 1)
}()
defer func() {
panic(1) // recovered, (overwritten by 2)
}()
}

= result:
2



// example E
func main() {
defer func() {
defer func() {
fmt.Println(recover())
}()
}()
panic(1) // not recover
}

= result:

panic: 1



// example F
func main() {
defer func() {
func() {
fmt.Println(recover())
}()
}()
panic(1) // not recover
}

= result (same as last one):

panic: 1




// example G
func main() {
defer fmt.Println(recover())
panic(1) // not recover
}

= result:

panic: 1


// example H
func main() {
defer func() {
fmt.Println(recover())
}()

func() {
func() {
panic(1) // recovered
}()
}()
}

= result:
1


So, it looks the calling of recover only takes effect only when both of the 
following two conditions are met:
1. the caller of calling recover must be a deferred function calling .
2. the panic must happened in (may not originate from) the caller function 
of caller of calling recover.

Where or not the calling of recover is deferred or not is not important.

Is the conclusion right?

-- 
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()

[John Souvestre]

Ø  .  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   
sync and   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 :

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  
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.com  .
For more options, visit https://groups.google.com/d/optout.

-- 

Re: [go-nuts] vim setup for auto go fmt on save.

[Fatih Arslan]

As others said you can just add a command to BufWritePost. However
don't forget that it's just runs it and is not able to capture any
parse errors and show you. It also might replace your current buffer
with the output of the error so you don't want it. Vim-go takes care
of it and has many other small improvements.

I understand you want something simple. Vim-go by default doesn't load
anything into your vim runtime. It's all lazily loaded and only is
executed if you run it (if you save it in our case).

On Mon, Oct 10, 2016 at 2:04 PM, 김용빈  wrote:
> Tank you Sander.
>
> I successfully installed and it works well.
>
> Still I want to know simple way though.
> If anyone knows about it, please let me know. :)
>
> --
> 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.



-- 
Fatih Arslan

-- 
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] Architect a daemon program

[Nick Craig-Wood]

On 11/10/16 18:09, Tong Sun wrote:
> I've searched the mlist archive and have learned that I should
> avoid daemonize as much as possible. So instead of label my program as a
> daemon (or singleton or anything), let me describe what I need to do. 
> 
> I need the program (say, named as`myprog`) to fork into the background
> (if possible) with the "start" command-line option.

You could try this

https://github.com/sevlyar/go-daemon

This implements the daemonization by re-running the executable with an
environment variable.

-- 
Nick Craig-Wood  -- http://www.craig-wood.com/nick

-- 
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 get: You are not currently on a branch

[Wojciech S. Czarnecki]

Dnia 2016-10-12, o godz. 02:37:16
Thomas Modeneis  napisał(a):

> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.

This is common to freshmen to get a checkout of some tag then
forget they did it. This is a root cause of update fails.

> Oh this is one of the problems that is really time consuming. I'm not sure 
> if this is related, but I've never had this kind of problems before +1.7.

Do you use any half-baked 'pkg versioning' tool?
If you did not checked by hand, such tool may be a culprit.

> Any ideas ?

Better education?

OK. Go get docs should have a warning box in red flash:

[ Either learn about git usage or never ever tinker within
 $GOPATH/src/github.com. If go get -u barks on you with 'You are 
not currently on a branch' message, cd into the mentioned directory and do:
'git checkout master' there. After that you may do 'go get -u' again. Rinse
and repeat. ]


-- 
Wojciech S. Czarnecki
   ^oo^ OHIR-RIPE

-- 
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 get: You are not currently on a branch

[Jan Mercl]

On Wed, Oct 12, 2016 at 2:27 PM Thomas Modeneis 
wrote:

> Oh this is one of the problems that is really time consuming. I'm not
sure if this is related, but I've never had this kind of problems before
+1.7.

Not being on a git branch is quite probably not caused by Go (regardless of
version).

> @Dave, I've tried your "quick-fix" but no luck ...
>
> $ go get google.golang.org/grpc
> # cd /opt/gocode/src/golang.org/x/net; git pull --ff-only
> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.

Dave's fix was to delete the repo, but the above clearly shows the repo
still exists. Maybe you have multiple GOPATHs? Another way how to attempt
to fix the problem is to go to the repository directory and trying

$ git checkout master

HTH

-- 

-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] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

[John Souvestre]

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 

 

ons 12 okt. 2016 kl 13:50 skrev John Souvestre :

Ø  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 :

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  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 

Re: [go-nuts] Re: go get: You are not currently on a branch

[andrey mirtchovski]

this is more of a git problem, not a go problem. you're in a 'detached
head' state and don't have a current branch to consider as your base.
the best remediation is to issue 'git checkout master' in the
respective repository. that will provide a correct head to work with.

for more info:

http://stackoverflow.com/questions/5772192/how-can-i-reconcile-detached-head-with-master-origin

On Wed, Oct 12, 2016 at 3:37 AM, Thomas Modeneis
 wrote:
> Oh this is one of the problems that is really time consuming. I'm not sure
> if this is related, but I've never had this kind of problems before +1.7.
>
> @Dave, I've tried your "quick-fix" but no luck ...
>
> $ go get google.golang.org/grpc
> # cd /opt/gocode/src/golang.org/x/net; git pull --ff-only
> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.
>
> git pull  
>
> package golang.org/x/net/http2: exit status 1
> package golang.org/x/net/trace: cannot find package "golang.org/x/net/trace"
> in any of:
> /usr/local/go/src/golang.org/x/net/trace (from $GOROOT)
> /opt/gocode/src/golang.org/x/net/trace (from $GOPATH)
> package golang.org/x/net/http2/hpack: cannot find package
> "golang.org/x/net/http2/hpack" in any of:
> /usr/local/go/src/golang.org/x/net/http2/hpack (from $GOROOT)
> /opt/gocode/src/golang.org/x/net/http2/hpack (from $GOPATH)
>
>
> On Saturday, May 28, 2016 at 7:42:27 PM UTC+2, Tong Sun wrote:
>>
>> How to fix the "You are not currently on a branch" error for `go get`?
>>
>> $ go get -u github.com/mattn/go-sqlite3
>> # cd .../src/github.com/mattn/go-sqlite3; git pull --ff-only
>> From https://github.com/mattn/go-sqlite3
>>  * [new branch]  gh-pages   -> origin/gh-pages
>>bbd33c0..38ee283  master -> origin/master
>>  * [new branch]  systemlib  -> origin/systemlib
>>  * [new tag] v1.0.0 -> v1.0.0
>>  * [new tag] v1.1.0 -> v1.1.0
>> You are not currently on a branch.
>> Please specify which branch you want to merge with.
>> See git-pull(1) for details.
>>
>> git pull  
>>
>> package github.com/mattn/go-sqlite3: exit status 1
>>
>>
> --
> 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] Function pointer vs interface for callback?

[shaun]

Hi,

I've been writing some code where I have nodes in a processing graph that 
need to notify other nodes when something changes.  I'm using callbacks 
(rather than channels, say) because I want everything to be synchronous. 
 It seems like I've got a choice between

type Foo struct {
Callback func(baz Biff) Boff
}

and

type callback interface {
func(baz Biff) Boff
}

type Foo struct {
Callback callback
}

to represent the callback reference.  Is there a convention (or a good 
argument) for when I should pick one or the other?  Seems like a function 
pointer is more universal (I don't even need an object to be a receiver) 
but maybe an interface is more idiomatic?

Thanks,

-Shaun


-- 
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] Re: go get: You are not currently on a branch

[Thomas Modeneis]

Oh this is one of the problems that is really time consuming. I'm not sure 
if this is related, but I've never had this kind of problems before +1.7.

@Dave, I've tried your "quick-fix" but no luck ...

$ go get google.golang.org/grpc
# cd /opt/gocode/src/golang.org/x/net; git pull --ff-only
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.

git pull  

package golang.org/x/net/http2: exit status 1
package golang.org/x/net/trace: cannot find package 
"golang.org/x/net/trace" in any of:
/usr/local/go/src/golang.org/x/net/trace (from $GOROOT)
/opt/gocode/src/golang.org/x/net/trace (from $GOPATH)
package golang.org/x/net/http2/hpack: cannot find package 
"golang.org/x/net/http2/hpack" in any of:
/usr/local/go/src/golang.org/x/net/http2/hpack (from $GOROOT)
/opt/gocode/src/golang.org/x/net/http2/hpack (from $GOPATH)


On Saturday, May 28, 2016 at 7:42:27 PM UTC+2, Tong Sun wrote:
>
> How to fix the "You are not currently on a branch" error for `go get`?
>
> $ go get -u github.com/mattn/go-sqlite3
> # cd .../src/github.com/mattn/go-sqlite3; git pull --ff-only
> From https://github.com/mattn/go-sqlite3
>  * [new branch]  gh-pages   -> origin/gh-pages
>bbd33c0..38ee283  master -> origin/master
>  * [new branch]  systemlib  -> origin/systemlib
>  * [new tag] v1.0.0 -> v1.0.0
>  * [new tag] v1.1.0 -> v1.1.0
> You are not currently on a branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
> git pull  
>
> package github.com/mattn/go-sqlite3: exit status 1
>
>
>

-- 
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] Re: go get: You are not currently on a branch

[Thomas Modeneis]

This issue is all over the web, people are having problems multiple times:

http://stackoverflow.com/questions/33064343/go-get-git-error-on-all-sources-but-golang-org
https://github.com/tools/godep/issues/60
https://github.com/golang/go/issues/6042
http://stackoverflow.com/questions/30188499/how-to-do-go-get-on-a-specific-tag-of-a-github-repository
https://github.com/gopherjs/gopherjs/issues/439
https://github.com/grpc/grpc-go/issues/807
https://github.com/kataras/iris/issues/245

Quote from one of the issues, people seem frustrated with Go package 
management:
"tamird  commented on Aug 1 

Yes, welcome to Go's terrible package management."

Any ideas ?

Cheers.

On Saturday, May 28, 2016 at 7:42:27 PM UTC+2, Tong Sun wrote:
>
> How to fix the "You are not currently on a branch" error for `go get`?
>
> $ go get -u github.com/mattn/go-sqlite3
> # cd .../src/github.com/mattn/go-sqlite3; git pull --ff-only
> From https://github.com/mattn/go-sqlite3
>  * [new branch]  gh-pages   -> origin/gh-pages
>bbd33c0..38ee283  master -> origin/master
>  * [new branch]  systemlib  -> origin/systemlib
>  * [new tag] v1.0.0 -> v1.0.0
>  * [new tag] v1.1.0 -> v1.1.0
> You are not currently on a branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
> git pull  
>
> package github.com/mattn/go-sqlite3: exit status 1
>
>
>

-- 
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()

[Henrik Johansson]

I mean https://github.com/golang/go/issues/5045

ons 12 okt. 2016 kl 13:50 skrev John Souvestre :

> Ø  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 :
>
> 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  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 

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()

[John Souvestre]

Ø  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 :

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  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()

[Henrik Johansson]

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 :

> 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  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.

[go-nuts] Re: Survey - do you use Go in the cloud?

[Ondrej]

Andrew,
Thanks for doing this. The Cloud Platform is great and I'm glad you're 
looking into this. Here are my 2c that didn't quite fit in the survey: when 
not running in a 'full' environment (lambdas/cloud functions, app engine, 
containers etc.), it would be good to keep the package/vendoring conundrums 
in mind, especially now as it's quite a live discussion as to what the best 
design of it should be. E.g. last time I tried Heroku, it forced me to use 
Godep, which was a bit annoying and I ended up dropping Heroku as an 
option, because I didn't want to change my workflows just for one 
environment.

Thanks!

On Tuesday, 11 October 2016 21:49:30 UTC+1, Andrew Jessup wrote:
>
> Hi Gophers,
>
> I'm on the Cloud Platform group at Google. We're trying to understand what 
> kinds of services Go developers are building that they plan to host with a 
> third party provider (any provider, not just Google) and why they picked Go 
> for doing so. 
>
> As such we're putting up a short (no, really - it's only 4 questions) 
> survey. 
>
> The survey is here - https://goo.gl/forms/XH5oXX106S7u7CMg2
>
> If you're building something to run in the cloud using Go, we'd love to 
> hear from you. We'll publish the (anonymized) results of this survey back 
> to this list for anyone else who is interested.
>
> Cheers,
>
> Andrew
>

-- 
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] Re: package versioning

[Peter Vypov]

On Wednesday, October 12, 2016 at 2:04:19 AM UTC+2, Eric Johnson wrote:

My view is that the general case requires putting such metadata in a 
> separate file for a package. 
>
Yes, I agree with you that having multiple Go files with such comments 
creates repetition (having to update multiple files) and forgetting to 
update one of those makes it ambiguous which particular version is going to 
be installed. 
 

> [...] after the current package management efforts nail down that metadata 
> file.
>
Having been working with dependency management tools such `godep` and 
`glide` would much prefer not to deal with any metadata files at all, with 
their location, format, and naming conventions.

How about an implied metadata file when you specify package versions on the 
`go get` command line but nowhere in source code or metadata files. Would 
such a tradeoff work? 

go get -u github.com/spf13/cobra:v1.10.0 \
  github.com/spf13/viper:v0.10.0 \
  github.com/pelletier/go-toml:v0.3.4


This has a drawback that dependent packages are going to be installed as 
their latest versions, so the ordering is important.

The reason for asking this question is that in recent months tools like 
`glide` (https://github.com/Masterminds/glide) gained popularity and some 
third-party packages require you to do `glide up` to populate it properly 
in addition / instead of the regular `go  get`. This means that for a 
package that uses such a glided package, you'd need to create a Makefile 
(or shell script) with a `glide up` and other non-`go` commands in it 
(which is ugly).
 

> 2) Support for "go run" type usage that automatically fetches 
> dependencies
>
> The second case seems possibly interesting, but implies a lot of mechanism 
> for a rare case.
>
I agree, maybe then just `go get` then `go run`?

Thanks for your answer! 

-- 
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

[Minglangjun Li]

On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis  wrote:

> If you have multiple CPUs (and the Go memory model assumes that you
> always can) they won't even write updated values from their cache out
> to main memory until they hit a lock.
> The reading CPU has read a value from main memory and put it in it's
> cache, it assumes that value won't change in main memory unless it
> hits a lock of it's own.
>
> If you don't lock then both CPUs will just sit in their own little
> world updating and reading values in their own caches and are never
> aware of each other.
>

Thanks Jesse. Good to know that.

On Wed, Oct 12, 2016 at 3:26 PM, John Souvestre  wrote:

> 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
>

Please forgive me for that. I haven't been familiar with 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.

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()

[John Souvestre]

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  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()

[Henrik Johansson]

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  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()

[John Souvestre]

Ø  … 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()

[John Souvestre]

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

[John Souvestre]

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.

Fwd: [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()

[Henrik Johansson]

Forgot the list, sorry.

-- Forwarded message -
From: Henrik Johansson 
Date: ons 12 okt. 2016 kl 08:32
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()
To: Dustin Hiatt 


Thats a good read but consider the following:

https://play.golang.org/p/j2XVkmcfRl

Is this adequately safe in light of the discussion in that thread?
Specially the last comment by +rsc seems interesting.

ons 12 okt. 2016 kl 07:39 skrev Dustin Hiatt :

I'm not entirely sure, but my gut tells me there's probably strict ordering
across threads there.  More info can be found here:
https://github.com/golang/go/issues/5045



On Wed, Oct 12, 2016 at 12:02 AM, Henrik Johansson 
wrote:

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.

ons 12 okt. 2016 kl 06:36 skrev :

You should only mutate variables inside the block that you are protecting
with the locks, in this regard they are similar to the mutexes in the
standard library.

Be careful with the spin locks though, I would only use them where low
latency is an absolute must, your go routines will sit there spinning in
the infinite loop until some other routine unlocks which is going to cost
CPU.


On Tuesday, October 11, 2016 at 11:20:15 PM UTC-5, Henrik Johansson wrote:

But do these types of spin locks provide the same memory effects as
standard locks? I get that only one goroutine at a time can run the given
block but assigning to shared vars inside the block will still need to use
the methods from sync/atomic right?


On Tue, Oct 11, 2016, 22:47   wrote:

The runtime.Gosched in the spin lock is going to be quite expensive.  I
found it's best to only do that every once and awhile, maybe every 100
iterations of the loop or so (you'll want to find optimal for your case).


On Tuesday, October 4, 2016 at 4:09:30 AM UTC-5, sphil...@gmail.com wrote:

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...@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.