Kees Varekamp | 23 Oct 02:04 2014

POODLE

I have been hearing about this POODLE vulnerability recently.

I am guessing this affects the vanilla ListenAndServeTLS? How to address it?

Thank you,

Kees


--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Brendan Tracey | 23 Oct 01:20 2014
Picon

Re: GCCGO Go compiled import pkg not found error

Ah, well that would explain it. Is there a reason this is not stated in https://golang.org/doc/install/gccgo ? Would have saved me some time…

On Oct 22, 2014, at 3:49 PM, Chris Manghane <cmang <at> google.com> wrote:

Hi,

Unfortunately gccgo does not work on Darwin (http://gcc.gnu.org/PR46986).  Sorry.

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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Tad Glines | 23 Oct 00:53 2014
Picon

[ANN] wfq - an implementation of the weighted fair queue algorithm

So I need to mux data over a single connection and wanted to prevent one flow from hogging the link. The weighted fair queue algorithm seems like a good solution.

I've implemented the algorithm in this package:

I welcome comments and suggestions.

One potential comment I'll address up front.
I chose not to use channels for two reasons:
1. Entry into the queue cannot be assessed pre-consumption when using channels.
2. While go routines are cheep, they are not free. The stack cost of 8K per goroutine adds up when you get in the 10's/100's of thousands of goroutines.

I find it easy to reason about conditionals so that's what I chose to use. I'm not opposed to channel based implementation suggestions as long as those suggestions would not lead to a loss of performance or an increase increase in complexity.

My primary concern is making sure that the queue actually behaves like a weighted fair queue. I'm fairly certain that it does in the case where all flows have the same weight. But, the one test that uses mixed weights only goes so far as to test that the higher priority flow finishes first. I'm also not entirely happy with TestMultiFlow because there is an element of probability to it seems unavoidable.

-Tad

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Gabriel Aszalos | 22 Oct 23:53 2014
Picon

Concurrently running multiple queries in the same transaction

I have a sequence in my code that runs 3 queries as part of the same transaction in order to deliver a message to its recipients. The 3 queries are:

1) Save the message
2) Enqueue delivery for external recipients
3) Deliver to local recipients

Since these happen sequentially, I've figure to make use of those go routines and run them in parallel. Now, has anyone tried this before and if so, do you see any potential issues with it? I know the DB connection pool is thread-safe, but does it apply to a transaction too?

Lastly, I feel this could add a significant speed improvement, am I wrong?

If it helps to visualize, here is a split diff before and after the change: https://github.com/gbbr/gomez/commit/1be4fa2a60ae82a08ee410f0e013a44bd68c365e?diff=unified

I haven't had time to write an actual benchmark for the 2 versions but if I don't get any good answers I will! :)

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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Justin Israel | 22 Oct 23:46 2014
Picon

Top N Go talks/slides for presenting to a team

Hey All,

So some discussion has come up in my team at work about Go, since I have been using it for a couple of my own projects so far, but we are predominantly a Python team, with some things also in Java/C++. I feel that I couldn't possibly do a better job of demoing the benefits of Go to my team than the existing video talks or slides that are out there (Rob Pike, Andrew Gerrand, ...), and I would love to get some input. 

If you had to pick 3 links to existing Go video talks or slides, to share with a team that writes pipeline tools and services in mostly Python, with some Java and C++, what would be your pick? 

Appreciate the feedback
- Justin

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Edward Price | 22 Oct 18:51 2014
Picon

Interfaces and Type Assertions

I am trying to wrap my head around the costs of type assertions on interface. I did an anecdotal exploratory benchmark that let me wanting.

https://gist.github.com/pricees/1737068f957137eea354

Can someone provide me with an explanation (response, blog post, video) of what is happening under the hood when a type assertion is made?


Lets say I have a struct Foo
Foo implements 2 methods: hi, bye

I have 2 interfaces:
  ImplementsHi (method set is hi())
  ImplementsHiAndBye (method set is hi(), bye())

My assumptions:
- Asserting type from ImplementsHiAndBye to Foo would be least costly. 
- Asserting type from an empty interface to Foo would be most costly
- Asserting type from ImplementsHi to Foo would be in the middle.

Is this fair to assume?
Is there some reflection magic going on somewhere?


Best,
Ted

ChicaGopher (see what I did there?)

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Dmitri Shuralyov | 22 Oct 07:51 2014
Picon

[ANN] gostatus - updated CLI in new version

Hi,

I've finally pulled the trigger and merged a PR that changes the command line interface of gostatus, a tool that tells you about any outstanding status of your Go package repos in your GOPATH.

Using it now should be more simple, because it's more like the go tool. Just like you can do `go list some/import/path`, you can now do:

gostatus some/import/path

Or more commonly run it on all of your Go packages:

gostatus all

It will tell you if:

-non-master branch is checked out
-there's a dirty working tree (i.e. git status is not empty)
-there's an updated version available (your revision doesn't match remote revision)
-you have a git stash

It works on git and mercurial repos (for other vcs you'll see "????" status).

If you're building some important package and want to find out the status of its dependencies, you can do:

# Show status of all dependencies (recursive) of package in cur working dir.
go list -f '{{join .Deps "\n"}}' . | gostatus --stdin -v

I modify many packages in place inside my Go workspace (either to add debug printfs, or to fix something and later make a PR, etc.), so I personally find it invaluable to find which packages have uncommitted changes and finalize or revert my changes, etc.

https://github.com/shurcooL/gostatus

If you find it useful, that's great.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Yongjian Lian | 22 Oct 05:58 2014
Picon

why sync.pool don't release the item that it holds the only reference unless the first poolCleanup() call

in go1.3.2 sync/pool.go

186 func poolCleanup() {
187     // This function is called with the world stopped, at the beginning of a garbage collection.
188     // It must not allocate and probably should not call any runtime functions.
189     // Defensively zero out everything, 2 reasons:
190     // 1. To prevent false retention of whole Pools.
191     // 2. If GC happens while a goroutine works with l.shared in Put/Get,
192     //    it will retain whole Pool. So next cycle memory consumption would be doubled.
193     for i, p := range allPools {
194         allPools[i] = nil
195         for i := 0; i < int(p.localSize); i++ {
196             l := indexLocal(p.local, i)
197             l.private = nil
198             for j := range l.shared {
199                 l.shared[j] = nil
200             }
201             l.shared = nil
202         }
203     }
204     allPools = []*Pool{}
205 }

here after the first poolCleanup() call, allPools is set to empty,and the pool is no longer put into allPools again?

162 func (p *Pool) pinSlow() *poolLocal {
163     // Retry under the mutex.
164     // Can not lock the mutex while pinned.
165     runtime_procUnpin()
166     allPoolsMu.Lock()
167     defer allPoolsMu.Unlock()
168     pid := runtime_procPin()
169     // poolCleanup won't be called while we are pinned.
170     s := p.localSize
171     l := p.local
172     if uintptr(pid) < s {
173         return indexLocal(l, pid)
174     }
175     if p.local == nil {
176         allPools = append(allPools, p)
177     }   
178     // If GOMAXPROCS changes between GCs, we re-allocate the array and lose the old one.
179     size := runtime.GOMAXPROCS(0)
180     local := make([]poolLocal, size)
181     atomic.StorePointer((*unsafe.Pointer)(&p.local), unsafe.Pointer(&local[0])) // store-release
182     atomic.StoreUintptr(&p.localSize, uintptr(size))                            // store-release
183     return &local[pid]
184 }         

here only p.local is nil will put p into allPools

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Mateusz Czapliński | 22 Oct 02:31 2014
Picon

trying to use c2go, panic: unexpected C type TypeKind(100017)

I'm trying to use code.google.com/p/rsc/c2go on (preprocessed) Lua 5.1 codebase, and I'm getting a panic like below. Could anyone help to workaround/fix this, or at least debug somewhat more to learn why this happens? The TypeKind 100017 seems to be c2go.String, if I understand correctly. (Files in tmp2go directory are copied from rsc/c2go.)

panic: unexpected C type TypeKind(100017)

goroutine 1 [running]:
runtime.panic(0x57c280, 0xc0840b39c0)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist772277431/go/src/pkg/runtime/panic.c:266 +0xc8
main.toGoType(0x0, 0x0, 0x0, 0xc084169b40, 0xc0840357b0, ...)
        C:/prog/gopath/src/github.com/akavel/goluago/internal/tmp2go/main.go:391 +0x3f0
main.toGoType(0x0, 0x0, 0x0, 0xc0840d2870, 0xc0840357b0, ...)
        C:/prog/gopath/src/github.com/akavel/goluago/internal/tmp2go/main.go:469 +0x878
main.rewriteTypes(0x2652b0, 0xc08400f320)
        C:/prog/gopath/src/github.com/akavel/goluago/internal/tmp2go/main.go:266 +0xd67
main.main()
        C:/prog/gopath/src/github.com/akavel/goluago/internal/tmp2go/main.go:70 +0x6be

goroutine 3 [runnable]:
main.func┬Ě020()
        C:/prog/gopath/src/github.com/akavel/goluago/internal/tmp2go/syntax.go:421 +0x47
created by main.init┬Ě1
        C:/prog/gopath/src/github.com/akavel/goluago/internal/tmp2go/syntax.go:423 +0x24

goroutine 4 [runnable]:
runtime.gosched()
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist772277431/go/src/pkg/runtime/proc.c:1370 +0x2a
runtime.gc(0x1)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist772277431/go/src/pkg/runtime/mgc0.c:2044 +0x2a3
runfinq()
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist772277431/go/src/pkg/runtime/mgc0.c:2322 +0x1f5
runtime.goexit()
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist772277431/go/src/pkg/runtime/proc.c:1396
exit status 2

The c2go code is slightly modified, to disable error on ((void) /*stuff*/) for now, but I think this wouldn't be related to the above?

diff -r c6452e6c462a cc/typecheck.go
--- a/cc/typecheck.go   Tue Jul 29 10:11:03 2014 -0400
+++ b/cc/typecheck.go   Wed Oct 22 02:26:38 2014 +0200
<at> <at> -822,6 +822,8 <at> <at>
                        x.XType = promote2(l, r)
                case l == r:
                        x.XType = l
+               //case l.Is(Func) && r.Is(Func) && isCompat(l, r):
+               //      x.XType = l
                case isCompatPtr(l, r):
                        x.XType = compositePtr(l, r)
                case isPtr(l) && isNull(x.List[1]):
<at> <at> -1082,10 +1084,10 <at> <at>
                if t == nil {
                        break
                }
-               if t.Kind == Void {
-                       lx.Errorf("cannot parenthesize void expression")
-                       break
-               }
+               //if t.Kind == Void {
+               //      lx.Errorf("cannot parenthesize void expression")
+               //      break
+               //}
                x.XType = t

        case PostDec, PostInc, PreDec, PreInc:

I'd be grateful for any help.
/Mateusz.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Brian Wolter | 22 Oct 02:24 2014
Picon

FD leak in http.Client

Hey all,

I've been seeing a FD leak issue in http.Client for a while now. I've read a lot of threads on this forum about issues that sound identical, all of which seem to have been resolved for the poster, but I'm still seeing the problem so I'm wondering if anybody else has had a similar problem and what they did about it.

Specifically, I'm running a service that executes a lot of HTTP requests (hundreds of thousands an hour). Slowly, over time, I can see that FDs build up until eventually I run out and have to restart the service. It doesn't seem to happen for every connection, but at the volume of requests I'm making it runs up pretty quickly.

Based on various things I've read, I'm doing the following things to try to guarantee these FDs get released, but to no avail:

- I am always calling rsp.Body.Close(),

- I am always consuming the response body, even if I don't do anything with it via: io.Copy(ioutil.Discard, rsp.Body)

- I have disabled keep-alive connections in http.Client (via the DisableKeepAlives property of Transport)

- I have disabled keep-alive connections in every individual request by setting req.Close = true,

- I am reusing the same http.Client instance for all these requests,

- I have even tried telling the underlying Transport to CloseIdleConnections after each request.

I've also noticed that the goroutines associated with those connections are also constantly increasing, blocked in an I/O wait state.

Is there something obvious I may be missing? I'm seeing this on go1.3.3 linux/amd64.

Thanks for any help,
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
MarkH | 21 Oct 23:56 2014
Picon

I've been reading about Windows and it's giving me a headache.

The more I read about the making of the many various kinds of "windows" the crazier the whole thing seems. It's like the wild mess Enron made before the whole thing blew up. It seems they started with one clean idea, message passing. But then, for some reason (maybe it didn't work well or maybe they wanted to do more), they added another layer of .dlls and tons of constants and distributed this far and wide with no recognizable scheme for making it all work together. Then, when that seems to have been unsuitable they added in the xml to simplify it. Mind you, this is just how it appears to me on first reading. Maybe it's just like a great murder mystery novel, where nobody knows what's going on and everybody done it.

Now I'm stuck, wondering if I should use windows at all. I'd like a mousey or touchscreen program for ease of use, but it seems ridiculously hard and maybe impossible to prove as correct. This isn't quite what I expected when I started this project.

Yes, I know somebody, maybe several somebodys, will tell me I'm an idiot and I need to read more, but frankly I'd rather not waste my time if I can make a better decision at this point: keep at it, use somebody else's library, write a nasty letter, etc.

Maybe this is why the Googlers aren't so hep on doing Windows stuff.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Gmane