[go-nuts] Avoiding function call overhead in packages with go+asm implementations

[Caleb Spare]

I've run into an annoying problem. I'm not sure if there's a solution
I've overlooked and I'm hoping you folks have some ideas for me.

I have a library that provides a function Sum64(b []byte) uint64. I
have both asm and pure-go implementations of this function, and I want
both to be as fast as possible.

It works like this today:

x.go:
func Sum64(b []byte) uint64 { return sum64(b) }

func sum64Go(b []byte) uint64 { /* go implementation here */ }

x_noasm.go:
func sum64(b []byte) uint64 { return sum64Go(b) }

x_amd64.go:
func sum64(b []byte) uint64 // asm implementation in x_amd64.s

This allows me to have both Go and x64 implementations of my function,
and furthermore, in x_amd64_test.go, I can compare both
implementations against each other by calling sum64 (asm) and sum64Go
(Go).

Problem 1 is that every call to Sum64 incurs double function-call
overhead because of the indirection to sum64. This overhead is
significant for smallish inputs. I can work around it by getting rid
of sum64 and declaring Sum64 twice (once in x_noasm.go and once in
x_amd64.go). This is annoying because I need to maintain duplicate
documentation comments.

Problem 2 is that the pure-Go version of Sum64 incurs triple
function-call overhead: Sum64 -> sum64 -> sum64Go. The only
workarounds I can come up with are to either forgo my tests which
compare the Go+asm implementations, or else maintain two independent
copies of sum64Go (one for noasm and one for amd64). Neither of these
seem acceptable to me.

Aram gave me the idea of using //go:linkname as a hacky workaround;
this doesn't work within a single package but I suppose I could
introduce an internal package for one of the implementations. That
seems fairly awful.

One tool change that would help with problem 1 but not problem 2 is if
a Go stub could have its body implemented in Go also. That is, x.go
could declare func Sum64(b []byte) uint64 with no body and then the
bodies would be provided in x_noasm.go (in Go) and x_amd64.s (in asm).

Another idea that would solve both problems is if the compiler could
inline the "forwarding" functions to avoid the extra call. Isn't that
much simpler than the general problem of inlining non-leaf functions?
I suppose there's still the stack trace issue.

Searching for that, I did find
https://github.com/golang/go/issues/8421. Any chance this could happen
in the near-ish term?

Or any other ideas?

-Caleb

-- 
You received this message because you are subscribed to the Google 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?

[Tom]

Thanks guys for your suggestions. I am going to try:

1. GODEBUG=netdns=go+2 or GODEBUG=netdns=cgo+2
2. Running with just IP addresses to eliminate DNS
3. Creating a minimal program to reproduce latency and post here

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


-- 
You received this message because you are subscribed to the Google 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] [ANN] - BoltHold - An embeddable NOSQL store for Go Types built on BoltDB

[Tim Shannon]

This is the first I've heard of storm, looks like it currently has more 
features (some I think I might try and implement in bolthold).  I think 
bolthold's querying is a bit simpler to understand, but I may be biased in 
that regard.

Storm definitely has the better name though :)

On Thursday, November 17, 2016 at 8:52:53 AM UTC-6, Diep Pham wrote:
>
> This looks very interesting. How does it compare to 
> https://github.com/asdine/storm? 
>
> Tim Shannon wrote: 
> > I've used BoltDB  in a quite a few 
> > projects, and have found it to be fast and very reliable.  But I've 
> > found that I was writing the same serialization and filtering code for 
> > each project, so I thought I'd try and build a more generic, reusable 
> > solution for storing and retrieving Go Types in a BoltDB file. 
> > 
> > https://github.com/timshannon/bolthold 
> > 
> > You simply open a BoltHold file and start inserting Go types: 
> > 
> > store, err := bolthold.Open(filename, 0666, nil) 
> > if err != nil { 
> > //handle error 
> > } 
> > err = store.Insert("key", { 
> > Name:"Test Name", 
> > Created: time.Now(), 
> > }) 
> > 
> > 
> > If you add the boltHoldIndex struct tag to your type, BoltHold will 
> > automatically add and update an index for that field: 
> > 
> > type Person struct { 
> > Name string 
> > Division string `boltholdIndex:"Division"` 
> > } 
> > 
> > 
> > You can use chainable queries to retrieve, delete, or update records in 
> > the BoltHold database. 
> > 
> > 
> bolthold.Where("FieldName").Eq(value).And("AnotherField").Lt(AnotherValue).Or(bolthold.Where("FieldName").Eq(anotherValue))
>  
>
> > 
> > 
> > In my preliminary benchmarks, I'm finding that the cost of serialization 
> > plus index updates don't add any significant overhead compared to disk 
> > access (which is to be expected), and adding indexes can significant 
> > improve read speed because you can avoid unnecessary disk accesses, 
> > however, I haven't written a lot of benchmarks, so any feedback you guys 
> > have on how they can be improved to be more accurate, I'd love to hear. 
> > 
> > || 
> > BenchmarkRawInsert-4  300  5351308ns/op 
> > BenchmarkNoIndexInsert-4  300  5421718ns/op 
> > BenchmarkIndexedInsert-4  300  5360532ns/op 
> > BenchmarkNoIndexUpsert-4  300  5468971ns/op 
> > BenchmarkIndexedUpsert-4  200  5700991ns/op 
> > BenchmarkNoIndexInsertJSON-4  300  565ns/op 
> > BenchmarkFindNoIndex-4 50 27340697ns/op 
> > BenchmarkFindIndexed-4   3000   368265ns/op 
> > 
> > It's a first release and the indexing and querying implementation is 
> > definitely what I would consider naive at this point, and I'm sure there 
> > are several improvements that can be made, however it's already proving 
> > to be a useful tool to me, and I'd love any feedback the community has 
> > to offer. 
> > 
> > There's lots more information in the README at 
> > https://github.com/timshannon/bolthold 
> > 
> > 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...@googlegroups.com  
> > . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How do I get around extending public interfaces that require private interfaces?

[lumjjb]

Thanks Alex for your insight. I am intrigued by the struct method that you 
mentioned, but like you suggested, it does add to the pain of fixing 
assertions of the type-checker, which conflicts with my original intent.

That makes sense and I have decided to fork the repo and work with the 
author moving forward. Thanks for the very detailed run down!

On Thursday, 17 November 2016 11:42:16 UTC-5, Axel Wagner wrote:
>
> The author of that package doesn't want you to reimplement that interface, 
> while still being able to declare variables and parameters of it. They 
> likely are using it as a replacement for union types, similar to what 
> go/ast  does.
>
> There is a way around it, but I want to unambiguously say, that this will 
> likely break assumptions of that package.
>
> The way around it, is to embed the interface in a struct:
>
> type Foo struct {
> original.Client
> }
>
> Now Foo implements original.Client and you can add your own methods to it. 
> However, type-assertions in original will likely break when you use Foo and 
> there is a possibility of failure when Foo.Client is not initialized.
>
> But, anyway: The author of original made clear that they don't want you to 
> make your own implementations of this interface. Your usecase, thus, is 
> unsupported and you will likely be in for a world of pain when ignoring 
> that. You could ask the original author to provide a way for you to 
> reimplement that interface, though.
>
> On Thu, Nov 17, 2016 at 4:52 PM,  wrote:
>
>> Hi, I've run into an interesting scenario, where I am trying to build a 
>> wrapper around a third party package's interface. I am stuck in terms of 
>> what to do and wanted to get some advice. I am also kind of puzzled why 
>> golang allows doing this since putting a private interface as part of the 
>> public interface doesn't quite make sense since it is not possible to even 
>> use that method. Appreciate the your help in advance!
>>
>> For example
>>
>> package original
>>
>> type Client interface {
>> DoSomething1 ()
>> DoSomething2 (int)
>>
>> privateInterface
>> }
>>
>> type privateInterface interface {
>> Method1 (privateInterface2)
>> }
>>
>> type privateInterface2 interface {
>> GenericMethod
>> }
>>
>> I want to extend the original interface with:
>>
>> package wrapper
>> import "original
>>
>> type Client interface {
>> original.Client
>>
>> OtherStuff()
>> }
>>
>>
>>
>> If anyone is wondering, the code that I am looking at is 
>> https://github.com/coreos/etcd/blob/master/client/client.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.

Re: [go-nuts] Reaching infinity

[Nikita Loskutov]

but on other hand defer triggered on panic too, maybe something with signals

четверг, 17 ноября 2016 г., 22:11:23 UTC+4 пользователь Nikita Loskutov 
написал:
>
> I'm not sure whether it makes sense, because I think the program can't 
> handle defer anyway, maybe something with recovery
>
> четверг, 17 ноября 2016 г., 19:46:07 UTC+4 пользователь Michael Jones 
> написал:
>>
>> Yes…that’s the point….an infinite defer that would have printed infinity
>>
>>  
>>
>> *From: *Nikita Loskutov 
>> *Date: *Wednesday, November 16, 2016 at 11:24 PM
>> *To: *golang-nuts 
>> *Cc: *, 
>> *Subject: *Re: [go-nuts] Reaching infinity
>>
>>  
>>
>> @*Michael Jones *I think nothing will changed in case of 
>> fmt.Println(math.Inf(0)) 
>> or defer,  because it never triggered.
>>
>

-- 
You received this message because you are subscribed to the Google 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] Reaching infinity

[Nikita Loskutov]

I'm not sure whether it makes sense, because I think the program can't 
handle defer anyway, maybe something with recovery

четверг, 17 ноября 2016 г., 19:46:07 UTC+4 пользователь Michael Jones 
написал:
>
> Yes…that’s the point….an infinite defer that would have printed infinity
>
>  
>
> *From: *Nikita Loskutov 
> *Date: *Wednesday, November 16, 2016 at 11:24 PM
> *To: *golang-nuts 
> *Cc: *,  >
> *Subject: *Re: [go-nuts] Reaching infinity
>
>  
>
> @*Michael Jones *I think nothing will changed in case of 
> fmt.Println(math.Inf(0)) 
> or defer,  because it never triggered.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How do I get around extending public interfaces that require private interfaces?

['Axel Wagner' via golang-nuts]

The author of that package doesn't want you to reimplement that interface,
while still being able to declare variables and parameters of it. They
likely are using it as a replacement for union types, similar to what go/ast
 does.

There is a way around it, but I want to unambiguously say, that this will
likely break assumptions of that package.

The way around it, is to embed the interface in a struct:

type Foo struct {
original.Client
}

Now Foo implements original.Client and you can add your own methods to it.
However, type-assertions in original will likely break when you use Foo and
there is a possibility of failure when Foo.Client is not initialized.

But, anyway: The author of original made clear that they don't want you to
make your own implementations of this interface. Your usecase, thus, is
unsupported and you will likely be in for a world of pain when ignoring
that. You could ask the original author to provide a way for you to
reimplement that interface, though.

On Thu, Nov 17, 2016 at 4:52 PM,  wrote:

> Hi, I've run into an interesting scenario, where I am trying to build a
> wrapper around a third party package's interface. I am stuck in terms of
> what to do and wanted to get some advice. I am also kind of puzzled why
> golang allows doing this since putting a private interface as part of the
> public interface doesn't quite make sense since it is not possible to even
> use that method. Appreciate the your help in advance!
>
> For example
>
> package original
>
> type Client interface {
> DoSomething1 ()
> DoSomething2 (int)
>
> privateInterface
> }
>
> type privateInterface interface {
> Method1 (privateInterface2)
> }
>
> type privateInterface2 interface {
> GenericMethod
> }
>
> I want to extend the original interface with:
>
> package wrapper
> import "original
>
> type Client interface {
> original.Client
>
> OtherStuff()
> }
>
>
>
> If anyone is wondering, the code that I am looking at is
> https://github.com/coreos/etcd/blob/master/client/client.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] Reaching infinity

[Michael Jones]

Yes…that’s the point….an infinite defer that would have printed infinity

 

From: Nikita Loskutov 
Date: Wednesday, November 16, 2016 at 11:24 PM
To: golang-nuts 
Cc: , 
Subject: Re: [go-nuts] Reaching infinity

 

@Michael Jones I think nothing will changed in case of fmt.Println(math.Inf(0)) 
or defer,  because it never triggered.

-- 
You received this message because you are subscribed to the Google 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: How can I make io.Reader stop reading?

[Alexander Menzhinsky]

I was able to solve the problem with the SetReadDeadline function. 
I check every n second some flag or channel whether to stop reading or not. 
In case you use net sockets and your reader is closed by other goroutine, 
the Read function will fail the next for loop iteration with the "reading 
from closed connection" error. 

for {
err := r.SetReadDeadline(time.Now().Add(5 * time.Second))
if err != nil {
return err
}
_, err = r.Read(buf)
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
// check whether t

continue
}
// ...
}

-- 
You received this message because you are subscribed to the Google 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] Attach files as part of resp

[vyasgiridhar27]

How can i attach files as a part of the http.ResponseWriter ? 

I have scoured through a ton of pages and am unable to find any method 
which works.

-- 
You received this message because you are subscribed to the Google 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] http.Client stops working after connected to VPN

[Diep Pham]

I have a program that periodically does a HTTP GET. The simplified codes
looks like that.

```
package main

import (
"log"
"net/http"
"testing"
"time"
)

func TestPlay(t *testing.T) {
for {
log.Println("starting request")
// If I use this, the test will hang forever!
// rsp, err := http.Get("http://google.com;)
client := http.Client{Timeout: time.Second * 3}
rsp, err := client.Get("http://google.com;)
if err != nil {
t.Fatal(err)
}
if err = rsp.Body.Close(); err != nil {
t.Fatal(err)
}
log.Println("request finished")
log.Println("sleeping...")
time.Sleep(time.Second * 1)
}
}
```



Problem is when a user connects to a VPN network, the request will fails
with following error.

```
main_test.go:17: Get http://google.com: net/http: request canceled
(Client.Timeout exceeded while awaiting headers)
```

And if I didn't set timeout in http.Client, it will hang forever!

So my questions are:
- is this normal, expected behavior of http.Client?
- what is the best way to handle this? beside just retry the request?

-- 
You received this message because you are subscribed to the Google 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 can I make io.Reader stop reading?

[Hoots The Owl]

As far as I understood, Daniel means something like 
that https://gowalker.org/github.com/northbright/ctx/ctxcopy

среда, 16 ноября 2016 г., 19:22:56 UTC+3 пользователь Alexander Menzhinsky 
написал:
>
> Do you mean io.CopyContext? I wasn't able to find it. 
>
> On Wednesday, 16 November 2016 18:22:25 UTC+3, Daniel Theophanes wrote:
>>
>> You can also use it.CopyContext and cancel the ctx. 
>
>

-- 
You received this message because you are subscribed to the Google 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] [ANN] - BoltHold - An embeddable NOSQL store for Go Types built on BoltDB

[Diep Pham]

This looks very interesting. How does it compare to
https://github.com/asdine/storm?

Tim Shannon wrote:
> I've used BoltDB  in a quite a few
> projects, and have found it to be fast and very reliable.  But I've
> found that I was writing the same serialization and filtering code for
> each project, so I thought I'd try and build a more generic, reusable
> solution for storing and retrieving Go Types in a BoltDB file.
> 
> https://github.com/timshannon/bolthold
> 
> You simply open a BoltHold file and start inserting Go types:
> 
> store, err := bolthold.Open(filename, 0666, nil)
> if err != nil {
> //handle error
> }
> err = store.Insert("key", {
> Name:"Test Name",
> Created: time.Now(),
> })
> 
> 
> If you add the boltHoldIndex struct tag to your type, BoltHold will
> automatically add and update an index for that field:
> 
> type Person struct {
> Name string
> Division string `boltholdIndex:"Division"`
> }
> 
> 
> You can use chainable queries to retrieve, delete, or update records in
> the BoltHold database.
> 
> bolthold.Where("FieldName").Eq(value).And("AnotherField").Lt(AnotherValue).Or(bolthold.Where("FieldName").Eq(anotherValue))
> 
> 
> In my preliminary benchmarks, I'm finding that the cost of serialization
> plus index updates don't add any significant overhead compared to disk
> access (which is to be expected), and adding indexes can significant
> improve read speed because you can avoid unnecessary disk accesses,
> however, I haven't written a lot of benchmarks, so any feedback you guys
> have on how they can be improved to be more accurate, I'd love to hear.
> 
> ||
> BenchmarkRawInsert-4  300  5351308ns/op
> BenchmarkNoIndexInsert-4  300  5421718ns/op
> BenchmarkIndexedInsert-4  300  5360532ns/op
> BenchmarkNoIndexUpsert-4  300  5468971ns/op
> BenchmarkIndexedUpsert-4  200  5700991ns/op
> BenchmarkNoIndexInsertJSON-4  300  565ns/op
> BenchmarkFindNoIndex-4 50 27340697ns/op
> BenchmarkFindIndexed-4   3000   368265ns/op
> 
> It's a first release and the indexing and querying implementation is
> definitely what I would consider naive at this point, and I'm sure there
> are several improvements that can be made, however it's already proving
> to be a useful tool to me, and I'd love any feedback the community has
> to offer.
> 
> There's lots more information in the README at
> https://github.com/timshannon/bolthold
> 
> Thanks,
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: How can I make io.Reader stop reading?

[Peter Waller]

Your original email was ambiguous and said "when a connection is closed",
so I gave an answer for when `connTwo` is closed. But your actual question
was "when `connOne`" is closed, if I'm understanding correctly given the
program you posted. So given the program above, if `dst` is closed you
should observe that one goroutine has terminated, correct? Then the
question is, "what about that other goroutine"?

The problem is that that other goroutine's Copy is sat in a loop like this:

for {
  read bytes from src (blocked here)
  write bytes to dst
}

`src` in this case has not been closed, so the only way you will notice if
`dst` has closed is if you read from `src`, either by closing `src` and
returning (via io.EOF) or reading bytes from `src` which then get written
to `dst` and cause a "the network connection is broken" style of error,
which io.Copy will return.

TL;DR: when the io.Copy(A, B) finishes, call A.Close() and the io.Copy(B,
A) will terminate. Calling A.Close() is like forwarding the B.Read()'s
io.EOF error.


On 16 November 2016 at 16:22, Alexander Menzhinsky 
wrote:

> Do you mean io.CopyContext? I wasn't able to find it.
>
> On Wednesday, 16 November 2016 18:22:25 UTC+3, Daniel Theophanes wrote:
>>
>> You can also use it.CopyContext and cancel the ctx.
>
> --
> You received this message because you are subscribed to the Google 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] httputil.ReverseProxy adding 100+ ms of latency on localhost - any ideas?

[Peter Waller]

Aha, sounds like the problem I was hitting, described in detail here:

https://groups.google.com/d/topic/golang-nuts/UXOVPX4a6uA/discussion

I didn't get any responses though so I was thinking it was a peculiarity of
my setup and didn't bother to file a bug.

If you run your server with GODEBUG=netdns=go+2 or GODEBUG=netdns=cgo+2
does the problem go away?

Does the example program in the above linked post have the same problem?

Are you running in a container? What is your environment? What libc and
userspace (Debian, Ubuntu, Alpine) are you using?

On 16 November 2016 at 05:01, 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.
>

-- 
You received this message because you are subscribed to the Google 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] Reaching infinity

[Nikita Loskutov]

Yes, it unused now, i removed it, thank you.

четверг, 17 ноября 2016 г., 13:46:46 UTC+4 пользователь Val написал:
>
> os.Args[1:]...  looks unused, I would remove it for sake of conciseness.
>
>

-- 
You received this message because you are subscribed to the Google 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] Reaching infinity

[Val]

os.Args[1:]...  looks unused, I would remove it for sake of conciseness.

-- 
You received this message because you are subscribed to the Google 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.