Windows platform go call DLL Pit

In recent projects, go was used to develop some service transit programs. The business is relatively simple, but there are some businesses that need to reuse code developed in the original C + +. In Windows, it's not too convenient to integrate C/+ + code with CGO. So use a DLL to encapsulate the C + + code, and then provide the basic API to complete the reuse. In this process encountered a number of problems and solutions, recorded, but also to meet similar or the same problem of people a reference.

If you do not know how to call the DLL in go, you can refer to this article "Windowdlls".

Limitations of callback

When Windows downgrades some APIs, it calls for incoming callback functions, which are very simple to use in C + + and pass directly to the function pointer. But in go this has the GC characteristic, but also has the runtime library the language to be slightly troublesome.

Go in order to solve this callback request, in the Syscall package provides the newcallback and newcallbackcdecl two functions to help users solve the callback problem. Specific callback mechanism here first, just to say that in go, the use of callback is limited. And there are corresponding requirements for the incoming go function. In the official version of go1.4 that I see, src/runtime/syscall_windows.go Line 71: Checks whether the number of callback exceeds the maximum limit, which is now 2000. An exception is thrown if it is exceeded. This is a very painful thing. And from the Go Issue library, the solution to this problem is a push and push.

So if you want to use callback, try to find ways to reuse, otherwise it will be very embarrassing.

Stack Overflow (0xC00000FD, _CHKSTK)

The problem is rather embarrassing. I encapsulated the DLL used by other colleagues to write code, his style is to write the function of the huge, in C + + run everything normal, but when the go written in the program call, the internal throws a 0XC00000FD error, that is, stack overflow.

The place is _CHKSTK. This function is a C + + compiler added to the code at the time of generation, so don't think about the arguments or whatever. This function is to say that when your function has more than a page-size variable, the compiler will insert the function header into the _CHKSTK call code, _CHKSTK will check the size of the stack is sufficient for the function of the local variables to use, if not enough, it will access the stack of guard PAGE, The system kernel is then triggered to check for this error, and the operating system expands the stack size. First of all there is a contradiction, the go language itself will expand the stack, and in order to do this will be the heap to use when the stack, but this time the problem is that it and the OS default stack space, causing the kernel to check the error is not extensible, this time the OS is not able to let the program can only be hung out. And the OS itself supports the stack extension is limited, unlike the go implementation of the stack extension, Windows under this extension will eventually trigger to a non-application of the stack address, if the stack can not be extended, or to let the program hang out. You can click here for a more detailed explanation of what's the purpose of the _CHKSTK () function. So the essence of the problem is that local variables are too large (self-disassembly DLL found that there really is a huge volume of object variables ...). The solution is to put the variables in the heap and put them in the heap. The final effect is to never throw this 0XC00000FD exception again.

Feelings

In fact, the above used in the C + + code, can be directly rewritten with go, but considering the cost of time, and finally gave up. Callback the problem I have temporarily rewritten the corresponding API code to get it done.

Go in the Write network communication, concurrency scene compared hi skins, but this cross-language interaction is really too painful. It only works and the egg hurts.

Windows platform go call DLL Pit