Re: [go-nuts] Strange behaviour of left shift

[James Bardin]

On Wednesday, December 5, 2018 at 11:55:25 AM UTC-5, Michel Levieux wrote:
>
> Well the only thing I do in the main is :
>
> fmt.Println(v)
>>
>
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
>
>
Nope. You're passing an untyped constant into an `interface{}`, so the 
compiler needs to pick a type from the specified defaults:

> The default type of an untyped constant is bool, rune, int, float64, 
complex128 or string respectively,

https://golang.org/ref/spec#Constants

-- 
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: Strange behaviour of left shift

[James Bardin]

On Wednesday, December 5, 2018 at 11:36:32 AM UTC-5, Michel Levieux wrote:
>
> which I assume works pretty well. But if I do the same in a test main and 
> try to 'go run' it, with this line :
>
> const v = 1 << 64 - 1
>>
>>
> I get the following error :
>
> ./testmain.go:8:13: constant 18446744073709551615 overflows int
>>
>
>
The const declaration is fine, what statement is at ./testmain.go:8:13? 
Chances are you're trying to implicitly convert `v` to an `int`.
See https://play.golang.org/p/7vtQSrU4o4o

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

[James Bardin]

On Saturday, May 5, 2018 at 9:30:25 AM UTC-4, s...@whites.team wrote:
>
> Hi James,
>
> Thanks for the tip - could you elaborate on your idea of a 'busy loop'? Is 
> this a loop that is blocked, or just one that is currently operating on 
> something? I'm not sure what causes GC to act on certain go routines.
>

Line 46 in your playground link is a busy loop, and line 57 is a busy loop 
when you don't need to change the number of goroutines. Nothing blocks the 
loops in those cases, so they spin using 100% cpu, eventually blocking the 
GC.
 

> I completely understand that getting the length of the channel isn't 
> accurate, but that part of the program doesn't need to be particularly 
> accurate or responsive, so it works okay in the instance.
>

Except it doesn't work OK here, because you're relying on polling the 
length with a busy loop, which isn't something you hardly ever want to do. 
You'll want to refactor this to use synchronization primitives rather than 
polling. 

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

[James Bardin]

On Saturday, May 5, 2018 at 6:27:54 AM UTC-4, s...@whites.team wrote:
>
> debug.SetGCPercent(-1) 
> stops the issue occurring - so I think we're onto a winner with the 
> garbage collection idea! Is there something I'm doing wrong that is causing 
> this GC binning off all of my go routines? 
>

You have a busy loop which you need to fix. 
Also, never branch based on the length of a channel being used 
concurrently. It's safe to read the value, but it's pretty much meaningless 
since it could change again before any action can be taken. 

-- 
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] if i catch resp.StatusCode != http.StatusOK and return early from my function, do i still have to close resp.Body??

[James Bardin]

Yes, always close the body in order to ensure the network connection is 
released. If you want to be able to reuse the connection, you should attempt to 
consume the body as well. 

-- 
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: Why does http client try to connect via IPv6 address when IPv6 is not enabled on machine

[James Bardin]

The net dialer sorts the addresses according to RFC6724, which means that 
since you don't have ipv6 enabled they go to the end of the list, but 
doesn't remove them entirely. Also if you're using the DefaultTransport 
from the net/http package, it has DualStack enabled which means that ipv4 
and ipv6 are tried nearly concurrently (RFC6555), so if the ipv4 host takes 
longer than 300ms to connect, the ipv6 racer will kick off too and you 
might get the ipv6 error as the final error if the connection fails.

In this case, you're only getting that error because the ipv4 connection 
has already failed, so it's harmless albeit somewhat confusing. If you 
disable DualStack all 8 ipv4 hosts would have to be down before the ipv6 
address is attempted, and if you never want to even see ipv6 addresses, set 
the dialer to only use the "tcp4" network.




On Saturday, December 30, 2017 at 11:51:39 AM UTC-5, bryan...@gmail.com 
wrote:
>
> I've done quite a bit of searching and can't seem to find a definitive 
> answer to my problem.
>
> I am periodically seeing errors where my code is doing an http get request 
> to a web service which offers both IPv4 and IPv6 connectivity.  My code is 
> running in a docker container without IPv6 enabled on a machine that also 
> doesn't have IPv6 enabled.  Yet go is trying to connect to this website via 
> IPv6 and I get a failure like dial tcp [:::XXX::XXXa]:443: 
> connect: cannot assign requested address.  The error makes sense, IPv6 
> connections aren't going to work from this machine.  The question is why is 
> go even trying to connect via IPv6 when that isn't an option on the machine?
>
> I've gone through and read quite a bit about the Go resolver and confirmed 
> it does request both the A and  records for a domain name.  This 
> particular service advertises 8 different IPv4 addresses and 1 IPv6 address 
> when I look at the returned address options.  I want to make sure Go 
> doesn't try the IPv6 address.
>
> Any suggestions on how I can keep Go from trying to use the IPv6 address 
> or better yet have it not even query for the  record?  Most of the time 
> I don't have problems but I'm seeing this error in my logs often enough 
> that it is concerning.
>
> Thanks!
>
> Bryan
>
>
>

-- 
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: What does the 1st :8 do in -- slice := (*[1 << 30]byte)(unsafe.Pointer())[:8:8]

[James Bardin]

On Wednesday, December 13, 2017 at 8:49:07 AM UTC-5, M.P. Ardhanareeswaran 
wrote:
>
> var i uint64 = 0xdeedbeef01020304
>>
>> slice := (*[1 << 30]byte)(unsafe.Pointer())[:8:8]
>>
>>
The fist 8 is the length, and the second is capacity. See "Full Slice 
Expressions" specification 
here: https://golang.org/ref/spec#Slice_expressions

-- 
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: Should net.Conn transform function retain the original data segmentation?

[James Bardin]

On Mon, Nov 20, 2017 at 12:01 PM, James Bardin <j.bar...@gmail.com> wrote:

> Though in this case I assume you must be using a TCP connection, so there
> is no concept of a "message" and hence to direct connection between the
> write size and the read size. If something other than UDP is expecting the
> full message in a single Read call, it is incorrectly written and you
> should file a bug.
>

(that should read " hence no direct connection ")

-- 
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: Should net.Conn transform function retain the original data segmentation?

[James Bardin]

Dave, should I then file a bug against net.UDPConn? ;)

Though in this case I assume you must be using a TCP connection, so there 
is no concept of a "message" and hence to direct connection between the 
write size and the read size. If something other than UDP is expecting the 
full message in a single Read call, it is incorrectly written and you 
should file a bug. 

On Saturday, November 18, 2017 at 8:28:18 PM UTC-5, Dave Cheney wrote:
>
> It is ok to pass data in smaller chunks, the io reader contract permits 
> that. If you find programs that fail to handle this id suggest raising a 
> bug. 

-- 
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: Why bytes Buffer's ReadFrom method blocked when read from a UDP connection?

[James Bardin]

You shouldn't use bufio around a UDP connection. The reads are a fixed 
size, so there's no "batching" of reads that could happen, and you can't do 
a partial read of a UDP packet, so you're going to lose data as soon if the 
buffer attempts to top off with a read smaller than the next packet size. 

-- 
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: How to run escape analysis on subpackage

[James Bardin]

On Thursday, September 14, 2017 at 10:58:27 AM UTC-4, Diego Medina wrote:
>
>
> go build -gcflags "-m -m" github.com/me/project-name/packagea and nothing 
> prints out, 
>
>
>
Nothing printed because it was already installed. 
You could update the timestamp on any of the package files, remove the 
existing object, or write a new one in a temporary location with 
`-o packagea.a`. 

Your workaround only succeeded because you were building a file rather than 
a package. 

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[James Bardin]

On Monday, September 11, 2017 at 5:53:10 AM UTC-4, Shivaram Lingamneni 
wrote:
>
>
> 1. Using `Listener.Close()` to interrupt the `Listener.Accept()` call 
> on the other goroutine 
> 2. Using a channel to tell the other goroutine that it should call 
> `Listener.Close()` itself and exit 
> 3. Using a channel to wait for the other goroutine to complete its 
> call to `Listener.Close()` 
>
>

Rather than waiting for just the `Listener.Close` call to return, try 
waiting for the call to `Listener.Accept()` to return with a non-Temporary 
error. That should error as the result of the file descriptor being closed, 
and give you the ordering you need.

-- 
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 1.9 introduced error on UDP Multicast JoinGroup

[James Bardin]

On Sunday, August 27, 2017 at 7:36:22 PM UTC-4, oldCoderException wrote:
>
> No.  I just downloaded and used 1.9 on its release last week.  I've 
> reverted to 1.8.3 for now and, as mentioned, it's working fine for me.
>
>
>>>
Are you certain you also have the latest version of golang.org/x/net/ipv4? 

-- 
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: runtime.GOOS case

[James Bardin]

They will always be lowercase, as the values are all defined in the code

const GOOS = `android`
const GOOS = `darwin`
const GOOS = `dragonfly`
const GOOS = `freebsd`
const GOOS = `linux`
const GOOS = `nacl`
const GOOS = `netbsd`
const GOOS = `openbsd`
const GOOS = `plan9`
const GOOS = `solaris`
const GOOS = `windows`

But it's usually better to rely on build constraints rather than 
conditionals at runtime. 



On Monday, August 7, 2017 at 5:00:24 PM UTC-4, Eric Brown wrote:
>
> This may be a completely stupid or trivial question; however...
>
> I currently use this on some old code I'm working on and trying to clean 
> things up:
>
> switch os := strings.ToLower(runtime.GOOS); os {
> case "windows":
>// do windows stuff here
> case "linux":
>// do linux stuff here
>
> default:
>// do default stuff here
>
> }
>
>
> I hate to import the entire strings package just to ensure that switch 
> will work.  Does anybody know if runtime.GOOS will always return a 
> lowercase value so I don't have to import the strings package just for this 
> single check?  All I can find is that GOOS returns (sys 
> .GOOS 
> )...
> I'd rather be safe than sorry.
>

-- 
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: Do we need to close response.Body before closing it?

[James Bardin]

On Wednesday, July 5, 2017 at 6:50:10 AM UTC-4, Yulrizka wrote:
>
>
> So in conclusion my question is do we need to always read the resp.Body 
> before closing it?
>
>
Yes, you need to read the body to reuse the connection, otherwise there may 
be still be data waiting to be read. 

You dug pretty deep here, but seemed to have skipped the documentation 
itself:

// The default HTTP client's Transport does not
// attempt to reuse HTTP/1.0 or HTTP/1.1 TCP connections
// ("keep-alive") unless the Body is read to completion and is
// closed.


-- 
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: why this goroutine always faster than main goroutine?

[James Bardin]

It's only polite to let other's know when cross-posting questions, to avoid 
wasting time.
https://stackoverflow.com/questions/44657084/why-main-goroutine-always-be-the-second-to-be-invoked

The answer and comments there seems to cover most aspects of the behavior 
you're seeing. 


On Tuesday, June 20, 2017 at 1:10:34 PM UTC-4, Jun An wrote:
>
> here is the code, why can't main goroutine be a little quick and exit then 
> discard another goroutine?
>
> package main
>
> import (
> "sync"
> "time"
> )
>
> func main() {
> var wg sync.WaitGroup
>
> wg.Add(1)
>
> go func() {
> wg.Wait()
> println("wait exit")
> }()
>
> go func() {
> time.Sleep(time.Second)
> wg.Done()
> }()
>
> wg.Wait()
> println("main exit")
> }
>
>
>
>

-- 
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: How to set value to empty interface{}

[James Bardin]

On Tuesday, April 11, 2017 at 10:10:25 AM UTC-4, Th3x0d3r wrote:
>
> AFAIK empty interfaces{} are passed by reference
>
>
Nothing in go is "pass by reference". The interface value is always copied. 

-- 
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: Shiny examples don't work on macOS Sierra 10.12.4

[James Bardin]

See https://golang.org/issue/19734


On Saturday, April 1, 2017 at 1:39:36 PM UTC-4, Dmitry Kravchenko wrote:
>
> After update to macOS Sierra 10.12.4 Shiny examples don't work anymore.
>
> iMac-Dmitry:~ dmitrykravchenko$ go env
>
> GOARCH="amd64"
>
> GOBIN="/Users/dmitrykravchenko/gowsp/bin"
>
> GOEXE=""
>
> GOHOSTARCH="amd64"
>
> GOHOSTOS="darwin"
>
> GOOS="darwin"
>
> GOPATH="/Users/dmitrykravchenko/gowsp"
>
> GORACE=""
>
> GOROOT="/usr/local/go"
>
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
>
> GCCGO="gccgo"
>
> CC="clang"
>
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/go-build413428417=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common"
>
> CXX="clang++"
>
> CGO_ENABLED="1"
>
> PKG_CONFIG="pkg-config"
>
> CGO_CFLAGS="-g -O2"
>
> CGO_CPPFLAGS=""
>
> CGO_CXXFLAGS="-g -O2"
>
> CGO_FFLAGS="-g -O2"
>
> CGO_LDFLAGS="-g -O2"
>
> iMac-Dmitry:~ dmitrykravchenko$ go run gowsp/src/
> golang.org/x/exp/shiny/example/basic/main.go
>
> signal: killed
>
> iMac-Dmitry:~ dmitrykravchenko$ go run gowsp/src/
> golang.org/x/exp/shiny/example/basicgl/main.go
>
> signal: killed
>
>
>
> Starting a program in IDEA Golang plugin also fails.
>
> "/private/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/Build gui.go and 
> rungo"
>
> GOROOT=/usr/local/go
>
> GOPATH=/Users/dmitrykravchenko/gowsp
>
> /usr/local/go/bin/go build -o 
> "/private/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/Build gui.go and 
> rungo" /Users/dmitrykravchenko/gowsp/src/ideprj/main/gui.go
>
>
> Process finished with exit code 137 (interrupted by signal 9: SIGKILL)
>
>

-- 
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: I cannot understand this channel behavior, is one channel ops affect another channel ops

[James Bardin]

Wasn't this already answered for you 
here? 
https://stackoverflow.com/questions/43152776/is-it-one-channel-ops-affect-another-channel-ops

On Saturday, April 1, 2017 at 1:35:12 PM UTC-4, Khalid Adisendjaja wrote:
>
> I made this simple script, trying to understand how is channel working, 
> somehow if channel "c" is sent after channel "b" is sent the last routine 
> is not being proceed,
> please see the runner function
>
> package main
>
> import (
>  "fmt"
>  "strconv"
>  "time"
> )
>
> func runner(idx int, c chan []int, b chan []int) {
>  var temp []int
>  fmt.Println("runner " + strconv.Itoa(idx))
>  bucket := <-b
>  for k, v := range bucket {
>   if v != 0 {
>temp = append(temp, v)
>bucket[k] = 0
>   }
>   if len(temp) == 5 {
>break
>   }
>  }
>
>  //Strange condition if channel c is sent after channel b is sent,
>  //somehow the last runner is not being proceed
>  b <- bucket
>  c <- temp
>
>  //All runner ara all proceed if c is sent first
>   // c <- temp
>   // b <- bucket
>
> }
>
> func printer(c chan []int) {
>  for {
>   select {
>   case msg := <-c:
>fmt.Println(msg)
>time.Sleep(time.Second * 1)
>   }
>  }
> }
>
> func main() {
>
>  c := make(chan []int, 5)
>  bucket := make(chan []int)
>
>  go runner(1, c, bucket)
>  go runner(2, c, bucket)
>  go runner(3, c, bucket)
>  go runner(4, c, bucket)
>
>  bucket <- []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 
> 16, 17, 18, 19, 20}
>
>  go printer(c)
>
>  var input string
>  fmt.Scanln()
>
> }
>
>
>  
>
>

-- 
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: gwenn/gosqlite, go1.8, runtime error: cgo argument has Go pointer to Go pointer

[James Bardin]

That package documents the behavior on all the relevant methods:

> Cannot be used with Go >= 1.6 and cgocheck enabled.

If you trust the author to have written something that is correct despite 
the checks done by cgo, you can disable cgocheck to use those methods. 


On Wednesday, March 8, 2017 at 10:54:15 AM UTC-5, Basile Starynkevitch 
wrote:
>
>
>
> On Wednesday, March 8, 2017 at 2:23:12 PM UTC+1, Tamás Gulácsi wrote:
>>
>> It's quite straightforward: gwenn/gosqlite has an error, by passing a Go 
>> pointer to the C side. This check is in effect since Go1.6.
>>
>> You should try to refresh your gosqlite library, or find a better 
>> maintained one.
>>
>
> AFAIU I'm using the latest commit of gosqlite. 
>
> What concrete sqlite glue library for Go do you recommend me, and most 
> importantly, how to configure log using  sqlite3_config 
>  with SQLITE_CONFIG_LOG? I'm ok 
> with any solution.
>

-- 
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] sort.Slice arguments

[James Bardin]

On Wednesday, March 8, 2017 at 10:01:08 AM UTC-5, Val wrote:
>
>
> - or the code in the less function will have to refer to the same 
> (unnamed) resliced portion, which is imo convoluted : fix 1 
>  or fix 2 
>  .
>

Having recently written code that is pretty much the same as fix #1, I 
wouldn't want vet to flag that as incorrect when it isn't.  That's more a 
lint issue, but I'm not convinced it's a problem when unit test coverage of 
the code should pick out the problem fairly quickly. 

-- 
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] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

[James Bardin]

On Friday, March 3, 2017 at 11:47:10 AM UTC-5, T L wrote:
>
>
> Yes, the suggestion needs more allocations in creating new string and 
> slice values.
> But it makes copying string and slice values a little faster and a little 
> less memory consuming.
>
>  
In most cases there is no difference between 1 word and 3 words, and is 
usually faster than an extra pointer dereference.

If you have a special case where the 3 words are costing you more than an 
extra pointer dereference, you can always use a pointer to a slice.

-- 
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: Problem calling http.HandlerFunc

[James Bardin]

The method expression 

(*Api).ListHandler

yields a function with the signature

func(*Api, http.ResponseWriter, *http.Request)

To use the method value with the signature

func(http.ResponseWriter, *http.Request)

you need an instance of `*Api` to call its method, so you can't assign the 
handler to the route until after you've initialized the `*Api`.

Don't try to initialize the routes in their top-level declaration, create 
the Api, then create the routes. 


On Friday, March 3, 2017 at 10:33:24 AM UTC-5, Dave wrote:
>
> Hi everyone,
>
> I just got started with GO and decided to attempt building an HTTP API 
> package using Gorilla Mux for an existing backend. 
> Unfortunately i have gotten stuck on an issue with initializing my routes 
> for the past couple of days. I tried searching for a solution online and 
> have read a ton of articles/tutorials but have not found exactly what i am 
> trying to do.
>
> The code is a little big to just paste and since it uses an external 
> import which play.golang does not support i attached it.
>
> My code does not compile returning:
> ./main.go:40: cannot use (*Api).ListHandler (type func(*Api, http.
> ResponseWriter, *http.Request)) as type http.HandlerFunc in field value
>
> Now i sort of understand why it says this because my ListHandler does not 
> adhere to the http.HandlerFunc signature as it is part of my Api struct but 
> this is where i am stuck.
>
> Any ideas on how to make this work or should i be doing something 
> completely different.
>
> (There could be some pointer errors here and there, i am still struggling 
> with those so try to overlook them :P and i mocked the backend struct as it 
> is in my opinion not relevant to the issue)
>
> - Dave
>

-- 
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] Slice from interface doesn't work as expected

[James Bardin]

All assignments are a copy, so there's no way to modify a slice value that 
is in an interface{}

Just like if this were a function argument, you will need a pointer in 
order to modify the value. 
https://play.golang.org/p/kOdXUCiT_F



On Thursday, March 2, 2017 at 9:01:48 AM UTC-5, Cornel Damian wrote:
>
> If you look where the slice is printed you will see that the data is 
> missing. In the working example from me the data is there.
> And even so, your example doesn't help me, what i've set there is just for 
> example, i my code each time i add data to the slice i must first cast it.
>
> On Thursday, March 2, 2017 at 3:56:58 PM UTC+2, Jan Mercl wrote:
>>
>> On Thu, Mar 2, 2017 at 2:46 PM  wrote:
>>
>> > Can somebody explain me why? 
>>
>> Did you mean https://play.golang.org/p/GUVZBUQlEj ?
>>
>> -- 
>>
>> -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: Handshake failed when using builtin TLS package: no cipher suite supported by both client and server

[James Bardin]

Sorry, I'm not really sure what's going on here. Just to test, have you
tried loading the cert temporarily without using autocert?

You probably need to setup a system to reproduce this and get more info. I
know there have been some issues in the past with WinXP and LetsEncrypt
certs, though I don't know if it's related as those caused invalid
certificate errors.

On Tue, Feb 7, 2017 at 7:01 AM, Alexandr Emelin <frv...@gmail.com> wrote:

> Copied wrong line from Heroku proxy report, here is the correct one:
>
> Chrome 49 / XP SP3
> <https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome=49=XP%20SP3=136>
>  RSA
> 2048 (SHA256)
> <https://www.ssllabs.com/ssltest/analyze.html?d=centrifugo.herokuapp.com#3605008a4b977a443f4f14e3c072d362c55475e7797b46554cc3088f8cbfa11b>
>TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
>
> вторник, 7 февраля 2017 г., 14:59:42 UTC+3 пользователь Alexandr Emelin
> написал:
>
>> James, thanks for response. I am using go1.7.5 linux/amd64
>>
>> I have no that client available too - it was originally seen in
>> production logs, and now I rely only on SSLLabs handshake emulation feature
>> that has that Chrome 49 SP3 client in list.
>>
>> Here is what SSLLabs shows for that client when application behind Heroku
>> proxy:
>>
>> Firefox 49 / XP SP3
>> <https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox=49=XP%20SP3=137>
>>  RSA
>> 2048 (SHA256)
>> <https://www.ssllabs.com/ssltest/analyze.html?d=centrifugo.herokuapp.com#3605008a4b977a443f4f14e3c072d362c55475e7797b46554cc3088f8cbfa11b>
>>TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
>>
>> For Go I used both examples from https://gist.github.com/FZambi
>> a/b51fa33ea4ec78caa7722299da5ae09e - one with default config, and one
>> with all available cipher suites set in TLSConfig and
>> PreferServerCipherSuites option. Both examples use autocert (Let's Encrypt)
>> to get HTTPS certificate. Output of SSLLabs in both cases is:
>>
>> Chrome 49 / XP SP3
>> <https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome=49=XP%20SP3=136>
>>  Server
>> sent fatal alert: handshake_failure
>>
>> And no cipher suite supported by both client and server in logs for this
>> handshake.
>>
>> понедельник, 6 февраля 2017 г., 17:15:04 UTC+3 пользователь James Bardin
>> написал:
>>>
>>>
>>> What cipher quite is negotiated when you connect to the Heroku proxy?
>>>
>>> What version of Go are you using on the server, and are you using the
>>> default tls.Config?
>>>
>>> I don't have that client directly available to test with, but does your
>>> particular client show the expected information when you visit
>>> https://www.ssllabs.com/ssltest/viewMyClient.html?
>>>
>>>
>>> On Sunday, February 5, 2017 at 3:44:47 AM UTC-5, Alexandr Emelin wrote:
>>>>
>>>> When using builtin TLS for http/websocket server I noticed that
>>>> handshakes from some old browser clients fail. The reason why I find this
>>>> strange is that other TLS implementations work with those connections
>>>> without any problems. I used ssllabs.com/ssltest/
>>>> <https://www.ssllabs.com/ssltest/> to emulate handshakes.
>>>>
>>>> To be more specific: clients using Chrome 49 on Windows XP SP3 can't
>>>> establish secure connection with my Go server. When I use Heroku reverse
>>>> proxy in front of the app - connection succesfully established using TLS
>>>> 1.2. In case of Go I see "*tls: no cipher suite supported by both
>>>> client and server*" message in server log.
>>>>
>>>> I investigated this a bit and found that actually client and server
>>>> have many cipher suites in common but none of them set in
>>>> setCipherSuite
>>>> <https://github.com/golang/go/blob/81038d2e2b588f9df45d20a2ca0be446b0e421b2/src/crypto/tls/handshake_server.go#L770>
>>>> function. Here is list of supported and preference suites:
>>>>
>>>> Supported: []uint16{0xc02f, 0xcca8, 0xcc13, 0xc014, 0xc013, 0x9c, 0x35, 
>>>> 0x2f, 0xa}
>>>> Preference: []uint16{0x5600, 0xc02f, 0xc02b, 0xc030, 0xc02c, 0xc011, 
>>>> 0xc007, 0xc013, 0xc009, 0xc014, 0xc00a, 0x9c, 0x9d, 0x5, 0x2f, 0x35, 
>>>> 0xc012, 0xa}
>>>>
>>>>
>>>> They are all rejected by this code
>>>> <https://github.com/golang/go/blob/81038d2e2b588f9df45d20a2ca0be446b0e421b2/src/crypt

[go-nuts] Re: Handshake failed when using builtin TLS package: no cipher suite supported by both client and server

[James Bardin]

What cipher quite is negotiated when you connect to the Heroku proxy?

What version of Go are you using on the server, and are you using the 
default tls.Config?

I don't have that client directly available to test with, but does your 
particular client show the expected information when you 
visit https://www.ssllabs.com/ssltest/viewMyClient.html?


On Sunday, February 5, 2017 at 3:44:47 AM UTC-5, Alexandr Emelin wrote:
>
> When using builtin TLS for http/websocket server I noticed that handshakes 
> from some old browser clients fail. The reason why I find this strange is 
> that other TLS implementations work with those connections without any 
> problems. I used ssllabs.com/ssltest/  to 
> emulate handshakes.
>
> To be more specific: clients using Chrome 49 on Windows XP SP3 can't 
> establish secure connection with my Go server. When I use Heroku reverse 
> proxy in front of the app - connection succesfully established using TLS 
> 1.2. In case of Go I see "*tls: no cipher suite supported by both client 
> and server*" message in server log.
>
> I investigated this a bit and found that actually client and server have 
> many cipher suites in common but none of them set in setCipherSuite 
> 
>  
> function. Here is list of supported and preference suites:
>
> Supported: []uint16{0xc02f, 0xcca8, 0xcc13, 0xc014, 0xc013, 0x9c, 0x35, 0x2f, 
> 0xa}
> Preference: []uint16{0x5600, 0xc02f, 0xc02b, 0xc030, 0xc02c, 0xc011, 0xc007, 
> 0xc013, 0xc009, 0xc014, 0xc00a, 0x9c, 0x9d, 0x5, 0x2f, 0x35, 0xc012, 0xa}
>
>
> They are all rejected by this code 
> 
>  (some 
> because there were no rsaSignOk set, some because there was no 
> rsaDecryptOk set).
>
> trying 0xc02f for version 0x303 
> reason rejected: !rsaSignOk
>
> trying 0xc013 for version 0x303 
> reason rejected: !rsaSignOk
>
> trying 0xc014 for version 0x303 
> reason rejected: !rsaSignOk
>
> trying 0x9c for version 0x303   
> reason rejected: !rsaDecryptOk
>
> trying 0x2f for version 0x303   
> reason rejected: !rsaDecryptOk
>
> trying 0x35 for version 0x303   
> reason rejected: !rsaDecryptOk
>
> trying 0xa for version 0x303
> reason rejected: !rsaDecryptOk
>
>
> I am not skilled in TLS area so looking for help – what's going on here, 
> why Go implementation does not support connections supported by other TLS 
> termination proxies?
>
>

-- 
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: Dynamic select/channel causes data race

[James Bardin]

Can you point to the actual source you're using? The filenames and line
numbers in the stack traces don't line up with the file you linked
originally.

-- 
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: Dynamic select/channel causes data race

[James Bardin]

Can you post the actual output from the race detector?


On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
>
> This causes a data race, and of course we only see it when running on a 
> beefy server with many cores :) I've never dealt with handling concurrency 
> and channels/selects when they're built dynamically using reflection. I've 
> tried surrounding the access on line 25 with a mutex but that does not 
> solve anything. Looking more into reflect.ValueOf() I see that it always 
> escapes to the heap as well as works with unsafe pointers in the 
> unpackEface() method 
> https://golang.org/src/reflect/value.go?s=61558:61591#L2073
>
> What is the proper way to handle the data race 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.

[go-nuts] Re: HTTP requests bottlenecks

[James Bardin]

First things I notice are that you're overriding the default dialer with 
one that doesn't timeout, and you've commented out ReadTimeout in the 
client. Both of those could indefinitely hold up client connections 
regardless of the DoTimeout call, which just ensures that the Do function 
returns before the deadline. 

Otherwise, I think you're going to have to instrument the code a little 
better to see what is holding you up. 


On Thursday, February 2, 2017 at 11:27:38 AM UTC-5, emarti...@gmail.com 
wrote:
>
> Thanks for the answer.
>
> Yes, it seems to be blocking, I just fixed it with: 
> http://blog.sgmansfield.com/2016/01/the-hidden-dangers-of-default-rand/
>
> After that change my code is working a lil bit better but still I see a 
> ton of timeouts + high latency on responses. Maybe the code is locking on 
> another part of the code?
>
> El jueves, 2 de febrero de 2017, 4:09:07 (UTC-3), land...@gmail.com 
> escribió:
>>
>> func randInt(min int, max int) int {
>> rand.Seed(int64(time.Now().Nanosecond()))
>> return min + rand.Intn(max-min)
>> }
>>
>> Is the culprit. the default rand locks globally for concurrent access. 
>>  You need to create a new rand in each goroutine you want to use it in, for 
>> maximum speed.
>>
>> On Wednesday, February 1, 2017 at 8:26:07 PM UTC-6, emarti...@gmail.com 
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm writing a POC for a future RTB platform. Basically I'm doing stress 
>>> tests by receiving HTTP requests and performing HTTP GET requests in the 
>>> background.
>>>
>>> Issue I face is that when i try to scale up, URLs starts to timeout. I 
>>> am trying to find what our bottleneck is but so far no luck (we aren't 
>>> running out of ephemeral ports).
>>>
>>> Remote URLs takes about 500ms-1000ms to respond. We are stress testing 
>>> it with wrk with 5000 concurrent requests. (5000 incoming requests which 
>>> translated into 30 remote URL requests = 150k requests)
>>>
>>> Here is our code:
>>>
>>> package main
>>>
>>> import (
>>>  "net/http"
>>>  "time"
>>>   "runtime"
>>>   "io"
>>>   "net"
>>>   "github.com/valyala/fasthttp"
>>>   "math/rand"
>>> )
>>>
>>> type HttpResponse struct {
>>>   url  string
>>>   response *http.Response
>>>   err  error
>>> }
>>>
>>> var urls = []string{
>>> //lots of urls
>>> }
>>>
>>>
>>> //func asyncHttpGets(urls []string) []*HttpResponse {
>>>
>>> var(
>>>  clients []fasthttp.Client
>>>  total_clients int
>>>  max_urls int
>>> )
>>>
>>> func init(){
>>> max_urls=30
>>>   clients =append(clients, create_client() )
>>> }
>>>
>>> func create_client() fasthttp.Client{
>>>
>>> return fasthttp.Client{
>>>  Dial: func(addr string) (net.Conn, error) {
>>> var dialer = net.Dialer{}
>>> return dialer.Dial("tcp", addr)
>>> },
>>>
>>> MaxIdleConnDuration:30*time.Second,
>>> MaxConnsPerHost:2024,
>>>  //ReadTimeout: 1*time.Second,
>>> }
>>> }
>>>
>>> func randInt(min int, max int) int {
>>> rand.Seed(int64(time.Now().Nanosecond()))
>>> return min + rand.Intn(max-min)
>>> }
>>>
>>>
>>> func asyncHttpGets(urls []string) []string{
>>>  ch:=make(chan string,max_urls)
>>> var responses  []string
>>>
>>>   cl:=0
>>>   for i := 0; i <= max_urls; i++ {
>>> url:=urls[i]
>>>   go func(url string) {
>>>
>>>req := fasthttp.AcquireRequest()
>>>  req.SetRequestURI(url)
>>>  req.Header.Add("Connection", "keep-alive")
>>>  resp := fasthttp.AcquireResponse()
>>>  clients[cl].DoTimeout(req, resp,1*time.Second)
>>>
>>> bodyBytes := resp.Body()
>>>   ch <- string(bodyBytes)
>>>
>>>   fasthttp.ReleaseRequest(req)
>>>   fasthttp.ReleaseResponse(resp)
>>>   }(url)
>>>   }
>>>
>>>   for {
>>>   select {
>>>   case r := <-ch:
>>>   responses = append(responses, r)
>>>   if len(responses) == max_urls {
>>>   return responses
>>>   }
>>>   }
>>>   }
>>>   return responses
>>> }
>>>
>>> func hello(w http.ResponseWriter, r *http.Request) {
>>>   results := asyncHttpGets(urls)
>>>   for _, result := range results {
>>>io.WriteString(w,"%s status: %s" + " " + result + "\n")
>>>   }
>>> }
>>>
>>>
>>>  func main() {
>>> runtime.GOMAXPROCS(0)
>>>
>>> server8000 := http.NewServeMux()
>>> server8000.HandleFunc("/", hello)
>>> http.ListenAndServe(":8001", server8000)
>>>  }
>>>
>>>
>>> Any help is really appreciated.
>>>
>>

-- 
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 "Declaring Empty Slices" of CodeReviewComments

[James Bardin]

None of those values are escaping or being used. Your only allocation is 
probably the call to fmt.Fprint.

This isn't something that really needs a benchmark, it should be obvious 
that t is nil in `var t []string`, and t is not nil in `t := []string{}`. 
The former doesn't allocate a slice header, while the latter does (though 
it may be in the stack). 



On Tuesday, January 31, 2017 at 12:15:40 AM UTC-5, Keiji Yoshida wrote:
>
> Hi,
>
> "Declaring Empty Slices" of CodeReviewComments ( 
> https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices 
> ) says as below:
>
> ```
> When declaring a slice, use
>
> var t []string
>
> rather than
>
> t := []string{}
>
> The former avoids allocating memory if the slice is never appended to.
> ```
>
> I executed a benchmark test against above code but I could not see any 
> difference between them as for the results.
>
> My benchmark test code and its results can be seen here: 
> https://github.com/keijiyoshida/go-code-snippets/blob/master/empty-slice-declaration/main_test.go
>
> Is there something wrong in my benchmark test code or procedure?
>
> Thanks,
> Keiji Yoshida
>

-- 
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] HTTP Server - Force close connection after response

[James Bardin]

Sorry, google groups UI doesn't make it clear that this was in response to 
Tony's last message.

`Connection: close` tells the client that the connection *will be closed*, 
it doesn't request that the client close the connection. Just set 
`Connection: close` and the server will do the right thing.

On Tuesday, January 17, 2017 at 7:06:44 AM UTC-5, James Bardin wrote:
>
> No, it signals to the client that the connection will be closed after the 
> completion of the response. 

-- 
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: http/2 client vs. GOAWAY

[James Bardin]

Form the SO link the frame was sent with ErrCode=NO_ERROR, which I would 
assume would be handled silently by the transport.

Not ruing out the ALBs doing something strange, but I would open an issue 
none the less.




On Wednesday, January 11, 2017 at 5:18:54 PM UTC-5, Brian Fallik wrote:
>
> Hello Gophers, 
>
> I'm trying to understand some behavior of Go's http client in 
> http2-mode. Our code uses http.DefaultClient and on the server side we 
> recently switched load balancers to a version that adds support for 
> http/2. 
>
> Go magically started using http/2 for us but now our clients 
> occasionally observe GOAWAY frames sent from the load balancer. This 
> manifests as a bug in the client since the error propagates up the 
> stack. I've posted more details on SO: 
>   http://stackoverflow.com/questions/41592929/aws-alb-http-2-and-goaway 
>
> I'm wondering if the http package expects users of the Client to 
> explicitly handle GOAWAY frames or not? If so this seems like a worthy 
> addition to the package docs since it's not obvious that the client 
> behavior can change based on the server support for http/2. 
>
> Thanks, 
> brian 
>

-- 
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: How to close all existing connections on http server

[James Bardin]

Up until now you had to implement that yourself.
In go1.8 the http.Server will have Close and Shutdown methods: 

 - https://tip.golang.org/pkg/net/http/#Server.Close
 - https://tip.golang.org/pkg/net/http/#Server.Shutdown


On Tuesday, January 3, 2017 at 10:52:29 AM UTC-5, laxman.v...@gmail.com 
wrote:
>
> Is there any way to close all the existing connections on http server??
>

-- 
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: Downloading go1

[James Bardin]

Can you build it from source?
The repo of course contains the entire history. 



On Thursday, December 1, 2016 at 4:57:30 PM UTC-5, freeformz wrote:
>
> For $reasons I need to download the original linux amd64 version of go1.
>
> Older go versions are stored under 
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/
>
> I have retrieved go1.0.1 (
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz)
>  
> and later successfully. 
>
> But I can't seem to find the right key for go1. I've tried:
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.linux-amd64.tar.gz
>  
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1-linux-amd64.tar.gz
>  
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.linux-amd64.tar.gz
>  
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0-linux-amd64.tar.gz
>  
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0.linux-amd64.tar.gz
>  
> 
>
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.0-linux-amd64.tar.gz
>  
> 
>
> All respond with: 
>  encoding='UTF-8'?>NoSuchKeyThe specified key 
> does not exist.
>
> I've also tried the getting an index (
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go
>  
> /),
>  
> like you can with https://storage.googleapis.com/golang/ (where modern go 
> releases are stored), but that just returns the same error.
>
> Can anyone point me to the right https://storage.googleapis.com url for 
> the go1 release?
>
> 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.

[go-nuts] Re: net.Conn.Read() performance

[James Bardin]

Conn.Read is a much higher level construct the using the syscalls directly. 
 The largest part of the overhead is coordinating with the network poller. 
There's also a slight overhead of using the net.Conn interface, so 
asserting the value to a *net.TCPConn may save you a little (though I'm not 
certain how much of a difference that makes in recent releases).

Using the syscalls, you're essentially dedicating a single OS thread to 
handle that socket's IO. 


On Wednesday, November 30, 2016 at 2:13:10 PM UTC-5, anto...@gmail.com 
wrote:
>
> Any thoughts, anyone?
>

-- 
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: net/http and errors.

[James Bardin]

If you want to assert your way down to the original error, the order of the 
structures returned from http.Get is:

if err, ok := err.(*url.Error); ok {
if err, ok := err.Err.(*net.OpError); ok {
if err, ok := err.Err.(*net.DNSError); ok {
fmt.Println("DNS ERROR:", err)
}
}
}

Again though, the action (http.Get) failed regardless of the reason, so you 
would usually the errors all in the same manner. You can't necessarily 
count on a DNS error being permanent either, just look at what happened a 
few weeks ago, when a huge number of major sites couldn't be resolved. 





On Monday, November 28, 2016 at 12:01:18 PM UTC-5, mb.dha...@gmail.com 
wrote:
>
> I'm downloading a large number of urls and the result is expected to have 
> failure reasons, DNS lookup failed being one.
>
> calling lookup manually would solve my issue, I suppose. Just wanted to 
> make sure that I'm not missing any obvious solutions.
>
> 1. lookup DNS and if it succeeds, 
> 2. try http.Get - which calles Lookup again (also maybe DNS server went 
> down now - improbable but not impossible?)
>
>
> On Monday, November 28, 2016 at 1:05:25 PM UTC+1, Dave Cheney wrote:
>>
>> What specifically do you want to handle about DNS errors ?
>>
>> If you have a set of possible dns names and you don't know if some of 
>> them are valid, you could use net.LookupHost to check which ones are valid 
>> before calling http.Get.
>>
>> On Monday, 28 November 2016 22:44:37 UTC+11, mb.dha...@gmail.com wrote:
>>>
>>> But AFIU, err.Temporary() could be true for other kind of errors that 
>>> might happen, isn't that a problem if I only want to handle DNS errors?
>>>
>>>
>>> On Friday, November 25, 2016 at 6:35:59 PM UTC+1, Victor Vrantchan wrote:

 In Go, you can check if a type satisfies a particular behavior by 
 declaring an interface, and then checking if the type satisfies that 
 interface. 
 In your case, you can check if the error is `Temporrary()` or not. 

 See this snippet as an example: https://I don't 
 thinplay.golang.org/p/Ffyg61iDpB 

 I recommend 
 https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
  
 and.or the GopherCon talk https://www.youtube.com/watch?v=lsBF58Q-DnY 
 by Dave Cheney for a more in-depth presentation of this idea. 

 On Friday, November 25, 2016 at 12:00:06 PM UTC-5, mb.dha...@gmail.com 
 wrote:
>
> This is a question about the net/http API, Googling was not very 
> helpful.
>
> _, err := http.Get("https://random_non_existing_domain.com;)
>
>
> Following code will obviously fail, but how can I check if it failed 
> because of DNS error not because a billion other things that might have 
> gone wrong?
>
> I tried this, (mostly as a shot in the dark)
>
> if e, ok := err.(net.Error); ok {
> fmt.Println("dial error", e.Temporary())
> }
> if e, ok := err.(*net.AddrError); ok {
> fmt.Println("addr rror", e.Temporary())
> }
> if e, ok := err.(*net.DNSError); ok {
> fmt.Println(e)
>
> and it seems to print 
>
>dial error false
>
> Is there any easy way to do what I'm trying to achieve?
>
> -
> dbalan
> @notmycommit
>
>
>

-- 
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: [Help] In a multi-threads application, when main function spins, the whole application hangs up

[James Bardin]

On Monday, November 21, 2016 at 2:23:37 PM UTC-5, zhaoguo wang wrote:
>
> Hi all,
>
> I wrote a simple application: the main function creates two goroutines, 
> while these two goroutines use RPC to do simple communication continually. 
>
> I found 
> *if the main function falls into a busy loop after creating the two 
> goroutines, *
> *the whole application will hang up after sending/receiving a couple 
> number of RPCs* (~80 on my testbed).
>
> Can anyone illustrate why this happens?  As each goroutine uses 
> independent Linux threads, why one spins can affect others?
>
>
Threads are independent, but there's still a single runtime scheduler. IIRC 
the busy loop is preventing the GC from being able to stop the world, which 
in turn ends up blocking the scheduler. 

 

> I use *runtime.GOMAXPROCS(4)* to make sure each goroutine uses a 
> Linux thread and the testbed is ubuntu 14.04 with 8 CPU cores. 
> I use the go1.7.3  library which is compiled from the source code. I also 
> attach the source code of the simple test, you should be 
> able to run it with "go run test.go".
>


Just never use a busy loop. A busy loop is always an error, and there's no 
reason to use 100% of a CPU just to block the main goroutine. You can use a 
WaitGroup, channel receive, or even an empty select statement to block 
efficiently if you want. 
 

 

-- 
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: http.NewRequest stopped to check SSL certificate validity every time

[James Bardin]

On Sat, Nov 19, 2016 at 11:33 AM, Vasily Korytov 
wrote:

> It stays there for days, so I'm not sure. And the client is supposed to be
> created and destroyed in a function that terminates, so I'm really
> surprised by that.
>
>
The connection can stay there for as long as the server and client want it
to. SSL handshakes are expensive, and normally you try to avoid them when
possible.

The client doesn't maintain the connection, the Transport does, and you're
using the DefaultTransport. I'm not sure why http.Get would work
differently, since it's just calling DefaultClient.Get.

-- 
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: http.NewRequest stopped to check SSL certificate validity every time

[James Bardin]

Chances are that you're getting better reuse of the client connections. If 
you want to ensure that you reconnect periodically use Request.Close when 
you don't want the connection maintained, or call 
Transport.CloseIdleConnections occasionally between requests to force the 
connections to close. 




On Saturday, November 19, 2016 at 9:07:58 AM UTC-5, Vasily Korytov wrote:
>
> P.S. I would like to line out things that changed since the SSL 
> certificate check was working:
>
> 1. Newer Go runtime
> 2. HTTP/2 connection
> 3. I used http.Get(url) before and now I use http.Client.Do (I use this 
> for customizing the User-Agent header)
>
> All the other things did not change, so the changed behaviour is a 
> surprise for me.
>
> Would appreciate any clues.
>

-- 
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: httputil.ReverseProxy adding 100+ ms of latency on localhost - any ideas?

[James Bardin]

On Thu, Nov 17, 2016 at 5:47 PM, Tom  wrote:

> I agree that creating a ReverseProxy object every time is inefficent with
> regards to transports - but surely that wouldnt cause the additional
> latency?


Depends on what exactly you're measuring and how you're testing.

A DNS query, TCP connect, or a TLS connection can all easily take 100+ms to
setup depending on latency, so losing the existing connection and starting
fresh every time could be an issue.

If you've used up the server's ephemeral ports with leaked connections, new
connection have to wait in queue for the old ones to timeout.

-- 
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: httputil.ReverseProxy adding 100+ ms of latency on localhost - any ideas?

[James Bardin]

While it might not be the initial problem, you're creating a new proxy and 
a new http.Transport on every request. At the end of that request that 
transport will probably still contain the open connection which you can no 
longer use. That's going to tie up the FD until the keepalive can kill it, 
which IIRC how Go sets the options in linux is going to be 10min with the 
30s interval you're setting.  

You always want to reuse http.Transports.


On Wednesday, November 16, 2016 at 12:01:50 AM UTC-5, Tom wrote:
>
> Hi guys,
>
> I've been working on a HTTP reverse proxy that has an auth/authorization 
> function. It all works well, however I have noticed significant additional 
> latency - and I cannot work out why. From what I can tell, me hitting my 
> service from chrome on localhost should work just fine - I have a very 
> beefy machine! (8core 3.4Ghz Amd64)
>
> Anyone have any insights into httputil.ReverseProxy, or have any ideas 
> where to begin?
>
> The method is here: 
> https://github.com/twitchyliquid64/pushtart/blob/master/src/pushtart/webproxy/handler.go#L61
>
> Cheers,
> Tom
>

-- 
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: Concurrently read map entries into a channel

[James Bardin]

On Sunday, November 6, 2016 at 12:00:33 AM UTC-4, Keith Randall wrote:
>
>
> You cannot modify the map in another goroutine while iterating.  Iterating 
> is considered a read operation for the entire duration of the read.  Writes 
> happening simultaneously with reads are a data race.
> "Entire duration" is the thing that's tripping you up, I think.  You can't 
> release the read lock inside the for loop.
> I'm afraid that for your use case you would need to read all the entries 
> (at least the keys) out of the map under a single read lock.
>


Is this still technically a "data race" though? It seems logically that the 
only memory read operation is happening in range clause evaluation, and 
locking around that should prevent concurrent map access. While it's a 
logical race in that the results are probably not really useful, I know I 
tried this once out of curiosity and the race detector does not report any 
problems with that locking pattern.  

-- 
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] CGO: Go string -> void*/length

[James Bardin]

C.CBytes does essentially this, but you either need to start with a []byte, 
or the string conversion could be a second copy.

I don't see a need for a separate version CString without the null when you 
can just pass the length-1. In the rare case that the extra byte makes a 
difference, you could just define your own version

func CStringNoNull(s string) unsafe.Pointer {
p := C.malloc(uintptr(len(s)))
pp := (*[1<<30]byte)(p)
copy(pp[:], s)
return p
}


On Monday, October 31, 2016 at 10:55:50 AM UTC-4, Peter Mogensen wrote:
>
>
>
> On 2016-10-31 15:39, Pietro Gagliardi wrote: 
> > Just pass the null-terminated string and use C.int(len(goString)) as the 
> length. 
>
> Yes... I mentioned that as a somewhat solution. ... it still allocates 1 
> byte more than needed. 
>
> /Peter 
>
>

-- 
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: http ssl "can't identify protocol"

[James Bardin]

It would really help if we had some complete code to reproduce the issue. 

It sounds like the server isn't closing connections, but with only these 
simple handlers I don't see where that could happen. Are there any Hijack 
calls, x/net/ipv4, or network related syscalls anywhere in your code?

Does this only happen with your custom tls.Config, or can you reproduce 
this with the default ListenAndServeTLS?

What is the request rate you're seeing when things start to fail?

-- 
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: net/http: In the infinite loop, refused all requests.

[James Bardin]

A busy loop is always a programming error, and there's no reason to do this 
is your code. If you actually did have a loop with no function calls that's 
somehow useful, you could add occasional calls to runtime.Gosched() to 
yield to the scheduler. 


-- 
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] How example can be run in test?

[James Bardin]

This is fixed in master. In go1.7 the Examples and Benchmarks aren't run if 
there are no Test functions. 

-- 
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 get creating strange git messages in bash. Any ideas what causes this ?

[James Bardin]

On Thu, Sep 15, 2016 at 5:53 PM, Joe Blue  wrote:

> thanks James
>
> You lost me here.
>

Where's here? O can try to provide more detail if you let me know what
you're not following. If you go into each repo that's not working and
checkout master, "go get -u" will work again.


> go get always pulls from master though ?
>
>
Yes, "go get" clones the master branch if there is no local copy, and runs
`git pull --ff-only` if the repo exists and the -u flag is provided (as you
see in the log).

-- 
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] go get creating strange git messages in bash. Any ideas what causes this ?

[James Bardin]

You have a few repos that aren't on a branch, so git can't pull and fast 
forward. You can checkout master in those repos, or delete them altogether and 
the next `go get` will fetch the current master branch. 

-- 
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] C.dll callback golang func will stuck

[James Bardin]

You have a busy loop in main. Use another method to block, like a read in 
stdin, wait for a signal, etc. 

-- 
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] Cgo Pointer Arithmetic

[James Bardin]

On Thursday, September 1, 2016 at 8:45:02 AM UTC-4, Luke Mauldin wrote:
>
> After I added the unsafe.Pointer conversion the code compiled: 
> https://play.golang.org/p/QTPyhZzKZH
>
> So my understanding is that line 15 is jut a pointer type conversion to 
> slice that is backed by the C array, so it doesn't matter if I choose 1 << 
> 20 entries or 1 << 22 entries, in both cases the runtime is just creating a 
> slice?
>
>
Yes, it's just a type conversion, and (*[1 << 20]Tag) is only a type. As 
long as the size is large enough to hold your data, have the slice 
operation be within bounds, and be within the size limits of the system, it 
doesn't matter so much.

 

> Another question, which of the two approaches (pointer arithmetic vs 
> iterating over sliced back by C array) is more efficient to create a Go 
> slice?  This code will be invoked hundreds of times per minute to convert 
> C arrays coming from C functions into memory safe Go slices that will then 
> be used throughout the Go program.
>
>
Hundreds of times per minute isn't very much. Once you've converted the 
array to a Go slice, it's accessed the same as any other Go slice. There's 
no need to calculate the pointer arithmetic by hand when you have the 
compiler to do that for you. 

-- 
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: net.Conn.Write is failing in golang

[James Bardin]

On Fri, Aug 26, 2016 at 5:46 AM,  wrote:

> I found it's hard to match *this particular error (*"broken pipe"*)*, and
> handle it accordingly, is there a solution?
>


What do you want to do with this particular error? How would you handle it
differently than any other permanent error?

The error is exactly the same as you would encounter using the C socket
api, on linux it's syscall.EPIPE.

-- 
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: Search for Another JSON Package

[James Bardin]

Can you use the json.Number type?

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



On Wednesday, August 24, 2016 at 5:30:10 AM UTC-4, dc0d wrote:
>
> Is there a JSON package that have these characteristics?
>
>
>- can marshal numeric integer values to strings (like 
>using `json:",string"` tag)
>- can unmarshal  numeric integer values from *either* string or the 
>number; based on the type of the field (some field like `MessageID int64`)
>
> Why? Because IEEE 754 is really annoying and JSON standard treats all 
> numeric values as `float64`. So when a big integer number (a big `int64` 
> for example) gets serialized - which does perfectly - it can not get 
> deserialized.
>

-- 
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] Differences in archive/zip between 1.6.3 / 1.7

[James Bardin]

Hi Radek,

There were a lot of performance improvements in the compress/flate package. 
https://tip.golang.org/doc/go1.7#minor_library_changes

-- 
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 there a function in standard lib to convert []T to a []interface{}?

[James Bardin]

https://github.com/golang/go/issues/15209

On Wednesday, August 3, 2016 at 11:20:01 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>>
>> On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>> >
>> > Often, I need converting a []T to []interface{} to use the []interface 
>> as a variable length parameter.
>> > But converting a []T for []interface{} in a for loop is neither clean 
>> nor efficient.
>> >
>> > So is there a function in standard lib to convert []T to a 
>> []interface{}?
>> >
>>
>> There is no function and it's not possible to define one in Go.
>>
>> Define your own function for your specific type or avoid []interface{} if 
>> you can. Usually what you want is to put a []T in an interface{} and use 
>> reflect instead.
>>
>
> fmt.Println needs a []interface{} parameter.
>  
>

-- 
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: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?

[James Bardin]

The issue here in essence is that an http.Server doesn't store a 
new.Listener to expose, it only operates on one provided to the Serve 
method. Without changing the api, there's no way to expose a listener in an 
http.Server in a way that doesn't interfere with the other methods.

However, I also don't like that it's not completely trivial to create your 
own listener identical to that used by the http.Server. The basic http 
server isn't so bad, but does make use of a small tcpKeepAliveListener 
wrapper. The https method is a little more complicated, since it may modify 
the tls.Config. 

Maybe we could propose helper functions or methods for Listen and 
ListenTLS, which return a net.Listener? (I feel like there were related 
issues files, but I'm not finding them at the moment)



On Wednesday, August 3, 2016 at 8:03:03 AM UTC-4, David Marceau wrote:
>
> I can understand at first glance we may perceive ListenAndServeTLS as a 
> convenience helper, but if enough people to copy and paste its contents to 
> modify it, then the sublety is
> the function is actually assumed to be part of a Foundation/Framework that 
> people build on top of. It is under the golang/net after all.  It was meant 
> simply to be used and extended, NOT rewritten.
>
> A framework usually has a manner in which to access all its 
> class/duck-type's attributes and services.  In this case the package net 
> has a number of duck-types, Client, Server.
> Most of the Server's attributes are accessible, but stunningly the 
> listener itself does not belong to the Server duck-type when I believe it 
> should.  Otherwise the other suggestion would be to make it available by 
> making it a return variable if other framework devs feel it shouldn't be 
> part of the Server duck-type.  For those that don't want to tweak the 
> listener, they can simply use the _ standard to ignore that return variable.
>
> That said, I believe the listener is core and should be available from 
> this one service.  I'm sure there are other developers that rely on 
> ListenAndServeTLS and implicit understand exactly what it does.  I'm not 
> asking to change anything in their understanding about its behaviour.  I 
> asking the golang team to change something to in its characteristics which 
> fundamentally belongs to the Server duck-type which extends its original 
> meaning to something developers assume to be there in the first place.  I'm 
> surprised 
>
> LimitListener(srv.tlsListener, connectionCount) is not part of the Server 
> duck-type's api.  It makes sense to be there.  I'm stunned it's not there.
> That's why I came to the forum to ask why it wasn't there the first place.
>
>

-- 
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: http response issue with leaking handles

[James Bardin]

On Fri, Jul 29, 2016 at 2:01 AM,  wrote:

> Thanks James, are there any golang tools which could have caught this
> issue. I know go vet didnt.


Caught the issue of using the first odd pattern for closing the response
Body?  There's no tool that can detect general logic errors in your
program, but good code review can go a long way.

-- 
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: http response issue with leaking handles

[James Bardin]

On Thursday, July 28, 2016 at 2:34:24 PM UTC-4, krma...@gmail.com wrote:
>
> WHere is this documented in "On error, any Response can be ignored. A 
> non-nil Response with a non-nil error only occurs when CheckRedirect fails, 
> and even then the returned Response.Body is already closed"
>
> I am interested in looking at it. I didnt find it here 
> https://golang.org/pkg/net/http/
>
>
> On Thursday, July 28, 2016 at 8:10:30 AM UTC-7, James Bardin wrote:
>>
>>
>> On Thu, Jul 28, 2016 at 11:08 AM, Ian Davis <m...@iandavis.com> wrote:
>>
>>> Great. Very clear.
>>>
>>> To those looking for this: it's a new comment added after 1.6.2
>>>
>>
>> Thanks, forgot I was on master.
>>
>>
^^ It was added after 1.6.2, and is in the current master branch. 

https://github.com/golang/go/blob/master/src/net/http/client.go#L176-L178
 

> Yes, this was implied by the error handling example in the docs, but now 
>> is much more explicit. 
>>
>

-- 
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: http response issue with leaking handles

[James Bardin]

On Thu, Jul 28, 2016 at 11:08 AM, Ian Davis  wrote:

> Great. Very clear.
>
> To those looking for this: it's a new comment added after 1.6.2
>

Thanks, forgot I was on master.

Yes, this was implied by the error handling example in the docs, but now is
much more explicit.

-- 
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: http response issue with leaking handles

[James Bardin]

On Thu, Jul 28, 2016 at 10:39 AM, Ian Davis  wrote:

> Is it? The http package only says:
>
> "When err is nil, resp always contains a non-nil resp.Body. Caller should
> close resp.Body when done reading from it."
>
> It doesn't say anything about the case where err != nil
>

> On error, any Response can be ignored. A non-nil Response with a non-nil
error only occurs when CheckRedirect fails, and even then the returned
Response.Body is already closed.

-- 
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: Someone reads req.Body even after client.Do ends in an http request,

[James Bardin]

To put it another way, excluding error conditions, the request isn't done 
until you've consumed the response body and closed it.


On Monday, July 25, 2016 at 3:11:01 PM UTC-4, fabian@gmail.com wrote:
>
> Hi,
>
> first, two points on the more obvious aspects:
>
>- The ContentLength header is just a hint for the server. Nothing 
>prevents you from setting the content length to some value (like 1896240) 
>and then sending a request body with a different size. The resulting 
>request might not be a valid HTTP request, but if you explicitly set the 
>ContentLength to an invalid value, there is nothing to prevent this.
>- The Read() function should return EOF to signal that all bytes are 
>read. As long as the reader does not return EOF, the caller must assume 
>that there are more bytes to be read.
>
> Taking these two points into account, the code basically sends an 
> infinitely long HTTP request with a false ContentLength header of 1896240. 
> As the request is infinitely long, the code will never finish sending this 
> request.
>
> The less obvious aspect of your question is: Why do you receive a response 
> when the request is never finished?
>
> The answer is found in a small comment in the implementation of Go's http 
> transport (
> https://github.com/golang/go/blob/master/src/net/http/transport.go#L1768-L1770
> ):
>
> // Write the request concurrently with waiting for a response,
> // in case the server decides to reply before reading our full
> // request body.
>
> Because of this optimisation, you receive a response while you are still 
> sending the request.
>
> The server interprets the ContentLength header and stops reading after 
> 1896240 bytes, and sends you the response. http.DefaultClient.Do(req) 
> returns the response, but in the background you continue sending your 
> infinitely long request.
>
> Hope this helps,
> Fabian
>
> On Monday, July 25, 2016 at 2:49:30 PM UTC+2, Feng Liyuan wrote:
>>
>> Set a io.Reader in http.NewRequest and do a http request, I found that 
>> someone reads the io.Reader even after the http request done.
>>
>> Is it a correct behaviour? And is it documented?
>>
>> My client code is
>>
>> package main
>> import (
>> "log"
>> "net/http"
>> "time")
>> type reader struct{}
>> func (r reader) Read(p []byte) (int, error) {
>> log.Println("READ")
>> return len(p), nil}
>> func (r reader) Close() error {
>> log.Println("CLOSE")
>> return nil}
>> func main() {
>> r := reader{}
>> req, _ := http.NewRequest("GET", "http://localhost:12306/;, r)
>> req.ContentLength = 1896240
>> resp, err := http.DefaultClient.Do(req)
>> if resp != nil {
>> resp.Body.Close()
>> }
>> log.Println("http.DefaultClient.Do", err)
>> time.Sleep(1e9)}
>>
>> and the server localhost:12306 simple write an http code and do nothing.
>>
>> This is the output of the program.
>>
>> [sunrunaway:/tmp]$ go run test.go 
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 READ
>> 2016/07/25 13:04:32 http.DefaultClient.Do 
>> 2016/07/25 13:04:32 READ
>>
>>

-- 
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] Segmentaion fault / static binary

[James Bardin]

FWIW, the "github.com/xeodou/go-sqlcipher" library isn't being linked 
correctly, and it seems to be trying to 
load /lib/x86_64-linux-gnu/libcrypto.so at runtime. 

Not sure what's at fault off hand, but "github.com/xeodou/go-sqlcipher" 
might be making some assumptions about being dynamically linked. 



On Monday, July 18, 2016 at 9:57:07 AM UTC-4, Konstantin Khomoutov wrote:
>
> On Mon, 18 Jul 2016 05:38:50 -0700 (PDT) 
> kumargv  wrote: 
>
> > But for me still it is giving same error 
> > I also updated to amd64 with go1.7rc1 
> > 
> > these are the dependence of the sample program 
> > 
> > linux-vdso.so.1 =>  (0x7ffca8fba000) 
> > libcrypto.so.1.0.0 
> > => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7fa93c071000) 
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 
> > (0x7fa93be6d000) libpthread.so.0 
> > => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fa93bc4f000) 
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 
> > (0x7fa93b886000) /lib64/ld-linux-x86-64.so.2 (0x55f1aa574000) 
> > 
> > i want to create a binary with all dependence ,so that it can run on 
> > any m/c without any problem 
> > Can you suggest something 
>
> Basically you have just transitioned to the world of C debugging. 
>
> The way to go, IMO, is: 
>
> 1) Make sure you have debug versions of the libraries your code depends 
>on.  Alternatively, they may have separate (extracted) debugging 
>symbols.  On your distro, that's usually a package with the -dbg 
>suffix, like libc6-dbg and libsslX.Y.Z-dbg. 
>
> 2) Figure out how to modify github.com/xeodou/go-sqlcipher so that it 
>builds its C stuff in debug mode.  Unfortunately, this, as I gather, 
>should be done in two places: its built-in copy of the SQLite 
>amalgamation and its cgo binding around SQLite and libcrypto. 
>
> 3) Build this stuff with code dumping enabled: 
>
>  $ ulimit -c unlimited 
>  $ ./yourprogram 
>
> 4) After it crashes, use `gdb` to load the dumped core file and your 
>program and then obtain the stacktrace of the code which crashed. 
>
>Refer to the GDB's docs on how to do that. 
>
> Having enabled debugging in cgo code and having debugging symbols of 
> the libraries used around should make gdb printout provide sensible 
> information on how it crashed.  Unfortunately, after that you'll have 
> to debug that further, and this requires knowledge of 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.