You can't arbitrarily create new threads on Unix systems either. The Go runtime more or less has to be in charge of threading.

Calling CreateThread in a Go program is not obviously useful. Is there a problem in more obviously useful code?

If you try to implement a Windows service in Go, calling StartServiceCtrlDispatcher will invoke the service main callback in a new thread. That's the motivating case for this issue. I used CreateThread in the example code because it's the simplest way to reproduce the issue.

Is this the Windows version of issue #227?

Not exactly. It looks like #227 involves forking a separate process, which you can do on Windows without an issue by calling CreateProcess. This is an issue with using Win32 API calls that spawn a new thread within the current process.

I think this is a dup of #6751.

Alex

Sorry about previous mistake comment.
I figure out pattern to reproduce. Below should work. Having import "C" seems initialize C runtime?

package main

import (
    "C"
    "fmt"
    "syscall"
)

func ThreadProc(p uintptr) uintptr {
    fmt.Println("FOO")
    return 0
}

func main() {
    modkernel32 := syscall.MustLoadDLL("kernel32.dll")
    procCreateThread := modkernel32.MustFindProc("CreateThread")
    r1, _, _ := procCreateThread.Call(0, 0, syscall.NewCallback(ThreadProc), 0, 0, 0)
    h := syscall.Handle(r1)
    syscall.WaitForSingleObject(h, syscall.INFINITE)
    syscall.CloseHandle(h)
}

We actually do allow calls from non-Go-created threads, provided cgo is in use. We should probably assume cgo is in use all the time on Windows, since it effectively is.

Dup of #6751.

Alex