<p dir="auto">by <strong>fuzxxl</strong>:</p>
<pre class="notranslate">The following code works under Go 1.2 but fails to compile with the most recent go tip
(4b3cdcb02f2d).

package cgotest

/*
#pragma pack(1)
struct foo {
    char c;
    int x;
};
*/
import "C"
import "unsafe"

func foo(f *C.struct_foo) int {
    return int(f.x)
}

This is what the correspond _cgo_type.go looks like:

type _Ctype_char int8
type _Ctype_int int32

type _Ctype_struct_foo struct {
        c       _Ctype_char
        _       [4]byte
}

In Go 1.2, the type definition used to have the x field instead of an underscore. This
looks like a regression to me.</pre>
<p dir="auto">by <strong><a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a></strong>:</p>
<pre class="notranslate">I'm seeing not-great TLS performance; enabling the ClientSessionCache seems to help. 
But it looks like even when resuming a session, we still call processCertsFromClient,
and do an (expensive) validation of the client cert chain.

Two ideas/questions:

1) Do we really need to re-validate the client cert on resume (haven't we already
validated it on first-connect)?  Can the client switch certs on us?

2) Is it possible to avoid any of this work using a cache?  processCertsFromClient looks
very cacheable to my untrained eye.  I'm thinking something similar to
ClientSessionCache in tls.Config.


I guess I could turn off client-cert validation by the tls package, and implement my own
cache.  It would sure be nice if this was out-of-the-box though!

Session resumption makes this less important, but I don't see why we wouldn't also cache
validation of server certs.</pre>