Re: [go-nuts] Re: can a program terminate, exit code 2, without an error?

[Konstantin Khomoutov]

On Fri, 7 Apr 2017 08:44:26 -0700 (PDT)
"'simon place' via golang-nuts"  wrote:

> using 'kill' to simulate an out-of-memory, i only get the string 
> 'terminated' and no go-routine dump.

I may be wrong but IMO in order to have a goroutine dump you have to
kill the program using the QUIT signal (plain `kill` sends TERM),
so one way to try is to do `kill -QUIT $pid`.

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

Re: [go-nuts] Re: Go 1.8.1 is released

[pedroso]

Nice graph 

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

RE: [go-nuts] Writing a non-blocking thread-safe buffer

[John Souvestre]

A few ideas…

 

Instead of using two channels, use just one.  Let the writer(s) use a “select” 
to do the write, else default to doing a read (then loop to try the write 
again).  I believe that would accomplish what you are doing now but with less 
overhead.

 

I think that it’s great that you implemented this with channels first.  If you 
need more throughput then I’d think mutexes next, and atomics as a last resort.

 

Perhaps using an array as a circular buffer with read and write accesses 
synchronized by mutexes would be a good next step.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Eno Compton
Sent: 2017 April 06, Thu 23:29
To: golang-nuts
Subject: [go-nuts] Writing a non-blocking thread-safe buffer

 

Hi All,

 

I'm trying to write a non-blocking thread-safe buffer for use in a high 
throughput system. In short, I want to create a buffer that decouples the speed 
of writes from that of reads. 

 

For a first attempt, using channels in the implementation seems best. Here is a 
link   to the current implementation. I 
have a write channel and a buffered read channel. As an intermediary between 
the two channels, I spin off a goroutine on initialization of the buffer which 
constantly pulls values off the write channel and attempts to put them on to 
the read channel. If the read channel is full, I discard a value from the read 
channel before inserting the new value.

 

This implementation works. What I seek to do now is improve the throughput of 
the buffer. I understand doing so requires proper benchmarking and measuring. 
What I'm curious about though is the experience of others on this list. In 
systems which require high throughput, am I best suited sticking with channels? 
Would atomics be an appropriate design choice? What about mutexes?

 

Forgive me if this question seems naive. I'm new to Go and am still developing 
a sense for the language.

 

Thanks,

 

Eno

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

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

[go-nuts] Re: Writing a non-blocking thread-safe buffer

[Albert Tedja]

I don't think using separate write/read channels do anything much here.  If 
you are concerned goroutines reading the channel somehow slowing down the 
writes, you already have a goroutine that's doing the transfer on the other 
end.



On Friday, April 7, 2017 at 8:36:14 AM UTC-7, Eno Compton wrote:
>
> Hi All,
>
> I'm trying to write a non-blocking thread-safe buffer for use in a high 
> throughput system. In short, I want to create a buffer that decouples the 
> speed of writes from that of reads. 
>
> For a first attempt, using channels in the implementation seems best. Here 
> is a link  to the current 
> implementation. I have a write channel and a buffered read channel. As an 
> intermediary between the two channels, I spin off a goroutine on 
> initialization of the buffer which constantly pulls values off the write 
> channel and attempts to put them on to the read channel. If the read 
> channel is full, I discard a value from the read channel before inserting 
> the new value.
>
> This implementation works. What I seek to do now is improve the throughput 
> of the buffer. I understand doing so requires proper benchmarking and 
> measuring. What I'm curious about though is the experience of others on 
> this list. In systems which require high throughput, am I best suited 
> sticking with channels? Would atomics be an appropriate design choice? What 
> about mutexes?
>
> Forgive me if this question seems naive. I'm new to Go and am still 
> developing a sense for the language.
>
> Thanks,
>
> Eno
>

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

[go-nuts] Re: Go 1.8.1 is released

[Nathan Kerr]

Thanks for all the hard work!

I have updated my go release timeline 
 visualization.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 1.8.1 is released

[Chris Broadfoot]

Hi gophers,

We have just released Go version 1.8.1, a minor point release.

This release includes fixes to the compiler, runtime, documentation, go 
command, and the
crypto/tls, encoding/xml, image/png, net, net/http, reflect, text/template, 
and time packages. 
https://golang.org/doc/devel/release.html#go1.8.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with "git 
checkout go1.8.1" and build as usual.

Thanks to everyone who contributed to the release.

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

[go-nuts] Go HTTP/2 behind HAProxy TLS Question

[bulat . shamsutdinov]

Hello!

I'm quite new to web development and currently bumped into a problem I 
can't wrap my head around.

I need to make a simple web server in Go using HTTP/2 and server will be 
deployed on Ubuntu 16.04 server behind HAProxy with TLS certificate from 
Let'sEncrypt. 

Here is a problem: in that setup, I don't need to setup encryption on the 
Go side (or can I even? certificate is issued using Certbot to HAProxy), 
HAProxy will take care of it, but to use HTTP/2 in my app I must use TLS 
there?

What am I getting wrong?
How to do it the right way?

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

[go-nuts] Writing a non-blocking thread-safe buffer

[Eno Compton]

Hi All,

I'm trying to write a non-blocking thread-safe buffer for use in a high 
throughput system. In short, I want to create a buffer that decouples the 
speed of writes from that of reads. 

For a first attempt, using channels in the implementation seems best. Here 
is a link  to the current 
implementation. I have a write channel and a buffered read channel. As an 
intermediary between the two channels, I spin off a goroutine on 
initialization of the buffer which constantly pulls values off the write 
channel and attempts to put them on to the read channel. If the read 
channel is full, I discard a value from the read channel before inserting 
the new value.

This implementation works. What I seek to do now is improve the throughput 
of the buffer. I understand doing so requires proper benchmarking and 
measuring. What I'm curious about though is the experience of others on 
this list. In systems which require high throughput, am I best suited 
sticking with channels? Would atomics be an appropriate design choice? What 
about mutexes?

Forgive me if this question seems naive. I'm new to Go and am still 
developing a sense for the language.

Thanks,

Eno

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

[go-nuts] Re: [blog post] go tool trace: Golang's hidden trace visualiser

[Stephen Russell]

Fantastic blog, thank you :) just wanted to let you know the demo doesn't 
work in safari.


On Thursday, 6 April 2017 18:00:55 UTC+1, Will Sewell wrote:
>
> Apologies. I just realised I didn't actually link to the post! It's here: 
> https://making.pusher.com/go-tool-trace/.
>
> On Thursday, 6 April 2017 17:29:22 UTC+1, Will Sewell wrote:
>>
>> Hi, I've just written a blog post/tutorial on Go's relatively unknown, 
>> but incredibly useful, trace visualiser: `go tool trace`. The post provides 
>> a tour of the interface, and examples of the kind of problems it can aid in 
>> tracking down.
>>
>> I was originally made aware of it by Rhys Hiltner in my previous message 
>> to this mailing list when I was investigating long GC pause times: 
>> https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. So 
>> thanks for pointing it out Rhys! As he mentions in that thread, it is 
>> currently not well documented, so I felt it was a good opportunity for a 
>> blog post after playing around with it for a bit.
>>
>> In the future I'd like to investigate and write about how the runtime 
>> event system itself actually works because it seems like an interesting 
>> area.
>>
>> Let me know if you have any feedback.
>>
>> Thanks,
>> Will
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] fatal error: runtime: cannot reserve arena virtual address space

[daniledty]

I use the suse11 with memory 512M, when suse reboot, the go runtime can not 
reserve  arena virtual address space. But when I manaully start the the 
service. it successfully started. Do anyone know why this happens?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] [ANN] Go Performance Playground

[dmitri]

We've recently launched Go Performance Playground, which was inspired by 
the original Go Playground.

It is available at https://play.stackimpact.com.

Example: https://play.stackimpact.com/p/zIRPhlywKG

Should be useful for quick CPU profiling, algorithm optimization and more. 
More information in the blog post: 
https://stackimpact.com/blog/golang-performance-playground/

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: [blog post] go tool trace: Golang's hidden trace visualiser

[Ondrej]

Excellent stuff. I remember finding out about trace over here

https://groups.google.com/forum/#!topic/golang-nuts/Ktvua7AGdkI

and I marvelled that there wasn't any documentation, so it was all trial 
and error for me. But what a gem. What a gem. Both the tool and your blog 
post.

On Thursday, 6 April 2017 18:29:22 UTC+2, Will Sewell wrote:
>
> Hi, I've just written a blog post/tutorial on Go's relatively unknown, but 
> incredibly useful, trace visualiser: `go tool trace`. The post provides a 
> tour of the interface, and examples of the kind of problems it can aid in 
> tracking down.
>
> I was originally made aware of it by Rhys Hiltner in my previous message 
> to this mailing list when I was investigating long GC pause times: 
> https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. So 
> thanks for pointing it out Rhys! As he mentions in that thread, it is 
> currently not well documented, so I felt it was a good opportunity for a 
> blog post after playing around with it for a bit.
>
> In the future I'd like to investigate and write about how the runtime 
> event system itself actually works because it seems like an interesting 
> area.
>
> Let me know if you have any feedback.
>
> Thanks,
> Will
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Bots on the mailing list

[C Cirello]

It looks like a similar technique that some spammers use to "untrain"
bayesian filter. If all words are meaningless, then all messages becomes
significant.

Il ven 7 apr 2017, 04:24 Ian Lance Taylor  ha scritto:

> On Mon, Apr 3, 2017 at 6:21 PM, Andrew Gerrand  wrote:
> >
> > As an experiment, I have banned those users from the group.
> > They can mail us if they have questions about it, at which point we can
> ask
> > them what the deal is with the forwarding.
> > I doubt we will hear from them.
> >
> > If anyone sees other addresses doing this, let me know.
>
> It hasn't helped.  I'm still getting e-mail messages.
>
> I may be missing something but I don't see how it could have helped.
> Those users aren't on the list.  And the e-mail messages aren't being
> sent back to the list.  They're being sent directly to people who send
> e-mail to the list.  Anybody could be doing this simply by scraping
> messages from the groups interface.
>
> Why anybody would do this, I don't know.  The messages have some
> garbage characters at the bottom.  Perhaps this is a modern equivalent
> of a numbers radio station: anyone in the know can get one of these
> replies just by sending an e-mail to the group, and since so many are
> sent out even tracing IP connections would not reveal who the intended
> recipient is.
>
> Ian
>
> > On 3 March 2017 at 07:56, Ian Lance Taylor  wrote:
> >>
> >> On Thu, Mar 2, 2017 at 12:32 PM, Nyah Check 
> wrote:
> >> >
> >> > Has anyone noticed there might be some bots subscribed to this mailing
> >> > list
> >> > that constantly forward discussions to our emails? I've noticed this
> >> > about 3
> >> > times already. I don't know if there's something the Group admins can
> do
> >> > something about.  Here are some of the emails I've found.
> >> > 1.) mott.barb...@yahoo.com
> >> > 2.) erminiak...@yahoo.com
> >> > 3.) thomas_ch...@yahoo.com
> >> > 4.) ryan_conk...@yahoo.com
> >> >
> >> > Apparently they're all "yahoo" email addresses.
> >>
> >> I have noticed this too.  i got at least two today.  I'm a group
> >> admin, but I can't think of anything to do.  The fact that the e-mails
> >> are sent from @yahoo.com doesn't imply that they are being triggered
> >> by e-mail sent to @yahoo.com, and even if it did we wouldn't know
> >> which specific @yahoo.com address is causing the problem.  And the
> >> e-mails being sent out are not going through the group, so there isn't
> >> anything we can do about them.
> >>
> >> I'm open to suggestions.
> >>
> >> Ian
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to golang-nuts+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Number of OS threads used by Go runtime

[C Banning]

Or: https://play.golang.org/p/ZgI19Z4uU1

On Thursday, April 6, 2017 at 9:37:55 AM UTC-6, Юрий Шахматов wrote:
>
> Hi all!
>
> Is there any way to count number of OS threads used by Go runtime 
> programmatically (ie without using bash with top/ps and others)? 
>
> --
> Best regards, Yuri
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: [blog post] go tool trace: Golang's hidden trace visualiser

[omarshariffdontlikeit]

This is awesome. Didn't even know this tool existed!

On Thursday, April 6, 2017 at 6:00:55 PM UTC+1, Will Sewell wrote:
>
> Apologies. I just realised I didn't actually link to the post! It's here: 
> https://making.pusher.com/go-tool-trace/.
>
> On Thursday, 6 April 2017 17:29:22 UTC+1, Will Sewell wrote:
>>
>> Hi, I've just written a blog post/tutorial on Go's relatively unknown, 
>> but incredibly useful, trace visualiser: `go tool trace`. The post provides 
>> a tour of the interface, and examples of the kind of problems it can aid in 
>> tracking down.
>>
>> I was originally made aware of it by Rhys Hiltner in my previous message 
>> to this mailing list when I was investigating long GC pause times: 
>> https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. So 
>> thanks for pointing it out Rhys! As he mentions in that thread, it is 
>> currently not well documented, so I felt it was a good opportunity for a 
>> blog post after playing around with it for a bit.
>>
>> In the future I'd like to investigate and write about how the runtime 
>> event system itself actually works because it seems like an interesting 
>> area.
>>
>> Let me know if you have any feedback.
>>
>> Thanks,
>> Will
>>
>

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