最近的项目中，使用了GO来开发一些服务中转程序。业务比较简单，但是有一些业务需要复用原有C++开发的代码。而在WINDOWS，用CGO方式来集成C/C++代码并不是太方便。所以用DLL把C++的代码封装起来，然后提供基本的API来完成复用。在这个过程中遇到了一些问题及解决方法，记录下来，也给遇到类似或者同样问题的人一个借鉴。
如果你还不清楚怎么在GO中调用DLL，可以参考这篇文章《WindowDLLs》。
Callback的限制
在WINDOWS下调用一些API时会要求传入回调函数，在C/C++下使用非常简单，直接传入函数指针就可以了。但是在GO这种有GC特性，又有运行时库的语言要稍微麻烦一点。
GO为了解决这种回调要求，在syscall包里提供了NewCallback和NewCallbackCDecl两个函数来帮助用户解决回调的问题。具体的Callback机制这里先不说了，只是说一下在GO里，Callback的使用是有限制的。而且对传入的GO函数也是有对应的要求。在我看的go1.4正式版本中，src/runtime/syscall_windows.go line 71:会检查callback的数量是否超过了最大的限制值，这个限制值目前是2000。如果超过就会抛出一个异常。这个是非常蛋疼的事情。而且从GO的ISSUE库里，这个问题的解决是一推再推。
GO的ISSUE里关于CALLBACK的事情已经很明确了，就是要让大家复用CALLBACK，也就是用全局函数来搞。在golang-china讨论组里，minux给予了这样的回答：
所以如果你要使用CALLBACK的时候，尽量的想办法复用，否则会很囧。
栈溢出(0xC00000FD, _chkstk)
这个问题比较囧。我封装的DLL里用到了另外同事写的代码，他的风格是把函数写的巨大，在C++下运行一切正常，但是当在GO写的程序里调用的时候，内部抛出了0xC00000FD的错误，也就是栈溢出。
发生的地方是_chkstk。这个函数是VS下的C++编译器在代码生成的时候加进去的，所以别想着通过参数啊什么的干掉了。这个函数的作用是说当你的函数内有超过了一页大小的变量时，编译器会把在函数头插入对_chkstk的调用代码，_chkstk会检查栈的大小是否足够该函数的局部变量使用，如果不够，它会访问栈的GUARD PAGE，然后会触发系统内核检查到该错误，这个时候操作系统会扩展栈的大小。首先这里就有矛盾了，GO语言本身会扩展栈，而为了做到这点就要把堆拿来当栈使用，但是这个时候的问题是，它和OS默认的栈空间不同，导致内核检查到的错误是不可扩展的，这个时候OS也搞不定了，只能让程序挂掉了。而且OS本身支持的栈扩展是有限制的，不像GO实现的栈扩展，WINDOWS下这个扩展最终会触发到一个无法申请的栈地址，如果无法扩展栈，还是要让程序挂掉。可以点这里《What is the purpose of the _chkstk() function》查看更详细的解释。所以问题的本质就是局部变量太大（自己反汇编DLL发现确实有个对象变量体积巨大...），解决方法就是该把变量该放到堆里的放到堆里的就放到堆里。最后的效果是，再也不抛出这个0xC00000FD的异常了。
感想
其实上面用到的C++代码，可以用GO直接重写的，但是考虑到时间成本，最后还是放弃了。CALLBACK的问题我是暂时重写了对应的API代码来搞定。
GO在写网络通信，并发场景时比较嗨皮，但是这种跨语言的交互操作实在是太蛋疼。只能且行且蛋疼了
Update:
这个问题后来被我提交给GO的开发团队了。具体详情可以见这里：https://github.com/golang/go/issues/9457
按照minux的说法就是需要在使用DLL时的，导入runtime/cgo即可。是说编译器编译的时候，发现没有使用CGO的话，就会把系统线程的栈大小设置为64KB，而且是不扩展的；但是如果使用 了CGO，就会变大默认栈，同时变为可扩展的。
最后还是得吐槽下，What the fuck！对于GO的这种使用方法真心不喜欢，实在是太蛋疼。CGO方式还要依赖GCC之类的玩意。WINDOWS下想愉快的玩耍根本不是太可能。改天再说下用GO来的感受。
