Re: [go-nuts] Deleting map entry from the top level of a nested map doesn't clean the underlying memory

[Urjit Singh Bhatia]

Hi Naveen,

Your expectations about the program immediately giving up memory on 
deleting an object are wrong.
If there is a need for you to have very tight memory controls, you could 
look into turning GC off entirely and managing memory yourself - See 
https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/
 for 
example
iirc jvm behaves similarly and doesn't return memory to the OS right away 
for perf reasons as Ian mentioned.


On Thursday, May 7, 2020 at 2:24:40 PM UTC-7, Ian Lance Taylor wrote:
>
> On Thu, May 7, 2020 at 11:57 AM Naveen Kak  > wrote: 
> > 
> > Ian, 
> > Any thoughts on this? Appreciate a response. 
>
> I'm sorry, I'm not sure what you want a response on. 
>
> Using top is a fine way to see total memory usage of your application. 
> It's a terrible way to examine the Go garbage collector.  Using 
> runtime.ReadMemStats will give you a better understanding of the 
> garbage collector. 
>
> Whether it makes sense to use sync.Pool depends on your application. 
> The sync.Pool documentation explains when it is useful. 
>
> Ian 
>
>
> > On Tue, 5 May, 2020, 8:34 PM Naveen Kak,  > wrote: 
> >> 
> >> Hi Ian, 
> >> I explored a few things, calling debug.FreeOSMemory periodically. This 
> does help, I see a definitely a change in the memory being returned to the 
> OS ( looking at top o/p). 
> >> I also set the "GODEBUG=madvdonotneed=1", as per go documentation post 
> 1.12 release, go release it uses "madvfree" option which is basically a 
> lazy free to the OS. 
> >> This didn't surprisingly did not have any effect. 
> >> So one thing for sure that deleting map definitely doesn't have any 
> bug, its the way GC is working, not releasing everything back to OS ( I 
> think after running for 12 hours or so, if we leave the system idle i don't 
> think memory gets released back to OS, GC probably thinks it will be 
> required to ask for memory so holds on to it unless we call the 
> debug.FreeOSMemory periodically). 
> >> 
> >> What you think about using "sync pools" so that there are no frequent 
> memory allocations/de-allocations?, haven't explored this much yet. 
> >> Another thing, calling debug.FreeOSMemory periodically does cause CPU 
> spikes. 
> >> 
> >> Regards 
> >> Naveen 
> >> 
> >> 
> >> 
> >> 
> >> On Wed, Apr 29, 2020 at 2:16 AM Ian Lance Taylor  > wrote: 
> >>> 
> >>> On Tue, Apr 28, 2020 at 1:00 PM Naveen Kak  > wrote: 
>  
>  Basically using the Top command at end of test. 
> >>> 
> >>> 
> >>> The top command will show you the memory that the program has 
> requested from the operating system and has not returned to the operating 
> system.   The Go memory allocator works by requesting memory from the 
> operating system as it needs it.  The Go garbage collector works by looking 
> at that memory and marking it as available for future allocations by the Go 
> memory allocator.  The Go garbage collector does not immediately return 
> memory to the operating system.  That is because requesting from and 
> returning to the operating system are relatively slow operations, and a 
> program that has needed memory once is likely to need it again. 
> >>> 
> >>> So the top program is not a good way to judge what the garbage 
> collector is doing.  It is an OK way to judge the maximum memory use of the 
> program, which will include memory that has been allocated and memory that 
> has been garbage collected. 
> >>> 
> >>> If a Go program runs for a while with excess memory, it will slowly 
> return it to the operating system.  You can encourage that process by using 
> runtime/debug.FreeOSMemory. 
> >>> 
> >>> In general, though, if you want to examine the garbage collector, I 
> recommend that you use runtime.ReadMemStats rather than top. 
> >>> 
> >>> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de8ddca2-45b9-4d3c-9e69-bba6f62140bb%40googlegroups.com.

Re: [go-nuts] Deleting map entry from the top level of a nested map doesn't clean the underlying memory

[Ian Lance Taylor]

On Thu, May 7, 2020 at 11:57 AM Naveen Kak  wrote:
>
> Ian,
> Any thoughts on this? Appreciate a response.

I'm sorry, I'm not sure what you want a response on.

Using top is a fine way to see total memory usage of your application.
It's a terrible way to examine the Go garbage collector.  Using
runtime.ReadMemStats will give you a better understanding of the
garbage collector.

Whether it makes sense to use sync.Pool depends on your application.
The sync.Pool documentation explains when it is useful.

Ian


> On Tue, 5 May, 2020, 8:34 PM Naveen Kak,  wrote:
>>
>> Hi Ian,
>> I explored a few things, calling debug.FreeOSMemory periodically. This does 
>> help, I see a definitely a change in the memory being returned to the OS ( 
>> looking at top o/p).
>> I also set the "GODEBUG=madvdonotneed=1", as per go documentation post 1.12 
>> release, go release it uses "madvfree" option which is basically a lazy free 
>> to the OS.
>> This didn't surprisingly did not have any effect.
>> So one thing for sure that deleting map definitely doesn't have any bug, its 
>> the way GC is working, not releasing everything back to OS ( I think after 
>> running for 12 hours or so, if we leave the system idle i don't think memory 
>> gets released back to OS, GC probably thinks it will be required to ask for 
>> memory so holds on to it unless we call the debug.FreeOSMemory periodically).
>>
>> What you think about using "sync pools" so that there are no frequent memory 
>> allocations/de-allocations?, haven't explored this much yet.
>> Another thing, calling debug.FreeOSMemory periodically does cause CPU spikes.
>>
>> Regards
>> Naveen
>>
>>
>>
>>
>> On Wed, Apr 29, 2020 at 2:16 AM Ian Lance Taylor  wrote:
>>>
>>> On Tue, Apr 28, 2020 at 1:00 PM Naveen Kak  wrote:

 Basically using the Top command at end of test.
>>>
>>>
>>> The top command will show you the memory that the program has requested 
>>> from the operating system and has not returned to the operating system.   
>>> The Go memory allocator works by requesting memory from the operating 
>>> system as it needs it.  The Go garbage collector works by looking at that 
>>> memory and marking it as available for future allocations by the Go memory 
>>> allocator.  The Go garbage collector does not immediately return memory to 
>>> the operating system.  That is because requesting from and returning to the 
>>> operating system are relatively slow operations, and a program that has 
>>> needed memory once is likely to need it again.
>>>
>>> So the top program is not a good way to judge what the garbage collector is 
>>> doing.  It is an OK way to judge the maximum memory use of the program, 
>>> which will include memory that has been allocated and memory that has been 
>>> garbage collected.
>>>
>>> If a Go program runs for a while with excess memory, it will slowly return 
>>> it to the operating system.  You can encourage that process by using 
>>> runtime/debug.FreeOSMemory.
>>>
>>> In general, though, if you want to examine the garbage collector, I 
>>> recommend that you use runtime.ReadMemStats rather than top.
>>>
>>> Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVpxfH4xL8uaO5BR3hKZUHpJj5DqG1GrtDpHsjudmuA6w%40mail.gmail.com.

Re: [go-nuts] Deleting map entry from the top level of a nested map doesn't clean the underlying memory

[Naveen Kak]

Ian,
Any thoughts on this? Appreciate a response.

Thanks
Naveen

On Tue, 5 May, 2020, 8:34 PM Naveen Kak,  wrote:

> Hi Ian,
> I explored a few things, calling debug.FreeOSMemory periodically. This
> does help, I see a definitely a change in the memory being returned to the
> OS ( looking at top o/p).
> I also set the "GODEBUG=madvdonotneed=1", as per go documentation post
> 1.12 release, go release it uses "madvfree" option which is basically a
> lazy free to the OS.
> This didn't surprisingly did not have any effect.
> So one thing for sure that deleting map definitely doesn't have any bug,
> its the way GC is working, not releasing everything back to OS ( I think
> after running for 12 hours or so, if we leave the system idle i don't think
> memory gets released back to OS, GC probably thinks it will be required to
> ask for memory so holds on to it unless we call the debug.FreeOSMemory
> periodically).
>
> What you think about using "sync pools" so that there are no frequent
> memory allocations/de-allocations?, haven't explored this much yet.
> Another thing, calling debug.FreeOSMemory periodically does cause CPU
> spikes.
>
> Regards
> Naveen
>
>
>
>
> On Wed, Apr 29, 2020 at 2:16 AM Ian Lance Taylor  wrote:
>
>> On Tue, Apr 28, 2020 at 1:00 PM Naveen Kak 
>> wrote:
>>
>>> Basically using the Top command at end of test.
>>>
>>
>> The top command will show you the memory that the program has requested
>> from the operating system and has not returned to the operating system.
>>  The Go memory allocator works by requesting memory from the operating
>> system as it needs it.  The Go garbage collector works by looking at that
>> memory and marking it as available for future allocations by the Go memory
>> allocator.  The Go garbage collector does not immediately return memory to
>> the operating system.  That is because requesting from and returning to the
>> operating system are relatively slow operations, and a program that has
>> needed memory once is likely to need it again.
>>
>> So the top program is not a good way to judge what the garbage collector
>> is doing.  It is an OK way to judge the maximum memory use of the program,
>> which will include memory that has been allocated and memory that has been
>> garbage collected.
>>
>> If a Go program runs for a while with excess memory, it will slowly
>> return it to the operating system.  You can encourage that process by using
>> runtime/debug.FreeOSMemory.
>>
>> In general, though, if you want to examine the garbage collector, I
>> recommend that you use runtime.ReadMemStats rather than top.
>>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHB4VaCt5c1BC3BhtcA%2BZ%2BoudFrkY8XY%2BGvGh7n%2BHmcgJOjEUw%40mail.gmail.com.

Re: [go-nuts] Type Assertion on File type

[Marvin Renich]

* André kouamé  [200507 12:57]:
> I want to check, if the value return by my function has the type *os.File
> This my code :
> func createFile(filename string) (*os.File, error) {
> f, err := os.OpenFile(filename, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
> return f, err
> 
> }
> //Test code
> filename := "testfile"
> f, _ := createFile(filename)
> c := (*os.File)
> fmt.Println(c)
> Error return : 
> invalid type assertion: f.(*os.File) (non-interface type *os.File on left) 
> Process exiting with code: 1

The value being coerced must be an interface type.  «f» above is of type
«*os.File», which is a concrete type.  This playground link shows an
example of what I think you want:

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

Note that «rdr» is of type «io.Reader», which is an interface that
«*os.File» implements.

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200507174509.bgqwrkx674gsnfvn%40basil.wdw.

[go-nuts] Re: DisableKeepAlive not being honored in http.transport

[Ryan Rank]

When I change to a different URI (https://foo.com/bar) it works as 
expected. So there's something with the original response that causes this 
to not work. I'm curious as to what, but this is working as designed and 
expected.

Thank you for the help!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4281625a-ea41-44d2-809e-cd32b53652f6%40googlegroups.com.

Re: [go-nuts] Type Assertion on File type

[Andy Balholm]

The problem is that the function’s return type is already *os.File (rather than 
io.WriteCloser or some other interface), so the type assertion is pointless. 

Andy

> On May 7, 2020, at 5:09 AM, André kouamé  wrote:
> 
> Hi,
> 
> I want to check, if the value return by my function has the type *os.File
> This my code :
> func createFile(filename string) (*os.File, error) {
> f, err := os.OpenFile(filename, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
> return f, err
> 
> }
> //Test code
> filename := "testfile"
> f, _ := createFile(filename)
> c := (*os.File)
> fmt.Println(c)
> Error return : 
> invalid type assertion: f.(*os.File) (non-interface type *os.File on left)
> Process exiting with code: 1
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e88406f6-7646-4cd9-9e0f-dfe6eae2581f%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BC68789B-21AE-4708-90A3-38FFAC3065B8%40gmail.com.

[go-nuts] Re: DisableKeepAlive not being honored in http.transport

[Ryan Rank]

Interesting. No headers coming back.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/06dddfe3-90ec-4e09-87bd-0e35db1f4021%40googlegroups.com.

[go-nuts] Re: DisableKeepAlive not being honored in http.transport

[Ryan Rank]

.98 is the client, .36 is the server.


This is the end of one transaction and the beginning of another. The client 
sends a FIN-ACK, then immediately starts the next transaction with the SYN 
packet. After that, the connection is ended; it looks like the client sends 
the RST packet. I'll take a look at DumpResponse. Hopefully I see something 
useful from that.

[image: wireshark screenshot.jpg]

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21eaedbb-86a3-4fd7-8ff9-388f5141e60f%40googlegroups.com.

[go-nuts] Type Assertion on File type

[André kouamé]

Hi,

I want to check, if the value return by my function has the type *os.File
This my code :
func createFile(filename string) (*os.File, error) {
f, err := os.OpenFile(filename, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
return f, err

}
//Test code
filename := "testfile"
f, _ := createFile(filename)
c := (*os.File)
fmt.Println(c)
Error return : 
invalid type assertion: f.(*os.File) (non-interface type *os.File on left) 
Process exiting with code: 1

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e88406f6-7646-4cd9-9e0f-dfe6eae2581f%40googlegroups.com.

Re: [go-nuts] terminating goruntime internal threads

[Pavan]

correction just to clarify in my previous mail : please read it as "around 
34 go internal pthreads"  instead of "around 34 goroutines"

Ian, the go internal pthreads left out after termination of all the 
goroutines have the data (few strings allocated in application) as it is. 
I am trying to measure RSS of my process after all goroutines terminate.  
It remains high, some of which seems to be part of go internal pthreads 
stack size. so i was thinking if there is a way to clean up these threads 
and see if RSS of application reduces. 

I am doing some more tests to confirm, if this stack size increase is due 
to memory leak bug in my go application .  

Yes , I was using LockOSthread because the C library we are using has some 
thread local storage used. 

Regards,


On Wednesday, May 6, 2020 at 11:45:34 PM UTC+5:30, Ian Lance Taylor wrote:
>
> On Wed, May 6, 2020 at 10:02 AM Pavan > 
> wrote: 
> > 
> > Thanks Ian. I start some 20 go routines and each routine involves 
> calling C functions and finally all go routines terminate. since each 
> goroutine uses LockOSThread at the begining, all the pthreads spawned as 
> part of goroutines exit too. 
> > 
> > Now i see around 34 goroutines, few of them have stack size of 7 MB as 
> seen in /proc/pid/smaps under Private_Dirty.  If i limit the stack size, 
> looks like memory is instead taken from heap. I am trying to reproduce with 
> simple example. Any thoughts/comments, Please share. 
>
> Goroutine stacks always come from the Go heap. 
>
> In a program that uses cgo, like yours, each thread will have a stack 
> allocated when the thread is created.  That stack is used when calling 
> C functions.  Note that this is each thread, not each goroutine.  Most 
> programs have many more goroutines than threads (but this is obviously 
> not true for goroutines that call LockOSThread). 
>
> Why do you call LockOSThread, and why do you let the goroutines exit 
> with the thread locked?  That is going to make your program run slower 
> and likely use more memory.  It makes sense if the C code uses 
> thread-local storage or if the C code modifies the thread in some way 
> that makes it unusable by future goroutines.  But without specific 
> reasons, it seems like a bad choice. 
>
> Ian 
>
>
>
>
> > On Saturday, April 25, 2020 at 6:51:37 AM UTC+5:30, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Fri, Apr 24, 2020 at 3:39 AM Pavan  wrote: 
> >> > 
> >> > how do we terminate the go generated internal OS threads.  I am 
> debugging an issue , where  RES(memory resdent size)  size of. a process 
> increases as goroutines used increases. 
> >> > Iam trying to reduce the threads footprint contribution of process 
> RES , hence.  terminate the additional threads once go routines are 
> completed. 
> >> > 
> >> > Is there an explicit call, I can make to terminate these processes. 
> >> > 
> >> > For the OS threads because of C functions calls, I am doing 
> LockOSThread and skipping unlock, so that they terminate as goroutine 
> terminates. 
> >> > 
> >> > I see some discussion of this here: 
> >> > https://github.com/golang/go/issues/14592 
> >> > but could not find if an explicit call was introduced for application 
> to call terminate. 
> >> 
> >> The trick using LockOSThread and returning from the function is 
> >> currently the only way to remove an existing thread.  In general the 
> >> Go runtime assumes that if you needed a thread once, you might need it 
> >> again at some point. 
> >> 
> >> If your memory usage increases without bound, it's fairly unlikely 
> >> that the problem is the number of threads.  It's much more likely that 
> >> you have a memory leak in your Go program.  Use the heap profiler. 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/94003c4b-9e29-4a41-8200-8b1cec062e19%40googlegroups.com.
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7540b664-c38d-4e54-bf8e-5cd173298c07%40googlegroups.com.

[go-nuts] Re: [ANN] Unicode text segmentation

[Matt Sherman]

Sorry, bad link. Here it is: https://github.com/clipperhouse/uax29

On Thursday, May 7, 2020 at 12:06:18 PM UTC-4, Matt Sherman wrote:
>
> Hi gophers, I’ve implemented Unicode text segmentation for Go: 
> https://github.com/clipperhouse/uax29/words
>
> It tokenizes text into words, sentences or graphemes according to the Unicode 
> spec . I’d been tokenizing text in ad 
> hoc ways, and then learned that there is a Unicode standard.
>
> Hopefully useful for you, feedback welcome. (I’m also talking to @mpvl 
> about how such functionality might be useful in x/text.)
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bbb890f3-ee1c-41f3-8468-d90b971b1977%40googlegroups.com.

[go-nuts] Re: flags package: shared flags and flag sets

[Manlio Perillo]

On Wednesday, May 6, 2020 at 2:08:25 PM UTC+2, Chris Burkert wrote:
>
> Dear all,
>
> I'd like to mix shared flags with flags specific to flag sets (cooltool 
>   ). However I struggle to parse the 
> shared flags only and pass the rest to the flagset for parsing. Here is 
> what I came up with:
>
> https://play.golang.org/p/Jazn3aSX9-d
>
> Do I have to pick a different flag library or can this be done with 
> package flag from the standard library?
>
>
Not sure if it can help, but look at:
https://github.com/perillo/cmd/blob/master/cmd.go

It is adapted from cmd/go subcommand code and use the standard flag package.


Manlio 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ec533424-3d6c-49a1-b19b-f5d038c838b9%40googlegroups.com.

[go-nuts] [ANN] Unicode text segmentation

[Matt Sherman]

Hi gophers, I’ve implemented Unicode text segmentation for 
Go: https://github.com/clipperhouse/uax29/words

It tokenizes text into words, sentences or graphemes according to the Unicode 
spec . I’d been tokenizing text in ad 
hoc ways, and then learned that there is a Unicode standard.

Hopefully useful for you, feedback welcome. (I’m also talking to @mpvl 
about how such functionality might be useful in x/text.)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/69cec677-b512-45a1-a9d6-592302d878ae%40googlegroups.com.

[go-nuts] Re: DisableKeepAlive not being honored in http.transport

[Amnon Baron Cohen]

In these situations I would normally use wireshark to look at the 
life-cycle of a single session.
Which direction are the FIN and RST packets going?
Are they sent from the client, or the server?
If the RST packets are sent by the server - i.e. the server is slamming 
shut the connection,
then the client can not reuse them and has to create new ones.

If foo is https, then this does make it harder to use tcpdump to look at 
the headers.
But you can print out the response headers sent bt foo.com using 
https://golang.org/pkg/net/http/httputil/#DumpResponse
and this should give you a bit more information.

Hope this helps...
- Amnon

On Thursday, 7 May 2020 15:13:04 UTC+1, Ryan Rank wrote:
>
> This is what I did, and see no change in behavior.
>
> for i := 0; i < 10; i++ {
> response, err :=client.Get("https://foo.com;)
> if err!= nil{
> panic(err)
> }
> ioutil.ReadAll(response.Body)
> response.Body.Close()
> }
>
> The network trace shows a SYN, SYN-ACK, ACK at the beginning of each HTTP 
> GET, and a FIN-ACK followed by some RST packets (those RSTs are common for 
> the foo.com in this case).
>
> I do know that foo.com honors keepalives because it's readily apparent 
> when I use *ab *to test.
>
> Also, I did upgrade to go 1.14.2 and nothing changed.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/33d4eca3-e80a-458b-9cdd-51fe6b674632%40googlegroups.com.

[go-nuts] Re: DisableKeepAlive not being honored in http.transport

[Ryan Rank]

This is what I did, and see no change in behavior.

for i := 0; i < 10; i++ {
response, err :=client.Get("https://foo.com;)
if err!= nil{
panic(err)
}
ioutil.ReadAll(response.Body)
response.Body.Close()
}

The network trace shows a SYN, SYN-ACK, ACK at the beginning of each HTTP 
GET, and a FIN-ACK followed by some RST packets (those RSTs are common for 
the foo.com in this case).

I do know that foo.com honors keepalives because it's readily apparent when 
I use *ab *to test.

Also, I did upgrade to go 1.14.2 and nothing changed.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8c85f57-f920-4426-890c-1ae2669726a6%40googlegroups.com.

Re: [go-nuts] Re: flags package: shared flags and flag sets

[Chris Burkert]

Thank you very much.
This is exactly what I was looking for. A simple way without the need for
additional packages.
Highly appreciated!

Am Do., 7. Mai 2020 um 07:28 Uhr schrieb mural :

> https://play.golang.org/p/Sga78gMLn-9
>
> You can then use it like './mycli -d stream -rt'
>
> The '-d' option is a shared flag, and `-rt' is dedicated for the
> subcommand 'stream'.
>
>
> On Wednesday, May 6, 2020 at 8:08:25 PM UTC+8, Chris Burkert wrote:
>>
>> Dear all,
>>
>> I'd like to mix shared flags with flags specific to flag sets (cooltool
>>   ). However I struggle to parse the
>> shared flags only and pass the rest to the flagset for parsing. Here is
>> what I came up with:
>>
>> https://play.golang.org/p/Jazn3aSX9-d
>>
>> Do I have to pick a different flag library or can this be done with
>> package flag from the standard library?
>>
>> Thanks - Chris
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1c81e2be-0920-4872-887e-19981a0543d1%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALWqRZpaZ032J_G88WM2vFz9w2e9vO9K_PSYO7-QeGK_5t6CbQ%40mail.gmail.com.