I'm building some system that consumes Lua as the embedded language. The user can interact with the system using Lua language (of course with some predefined interface). But right now, I have no idea how to limit the execution time (memory consumption can be limited with lua_Alloc).

The why is there no goroutine ID may be relevant here. It explains that it is a deliberate design decision. Quoting from the first paragraph:

Goroutines do not have names; they are just anonymous workers. They expose no unique identifier, name, or data structure to the programmer. Some people are surprised by this, expecting the go statement to return some item that can be used to access and control the goroutine later.

Also:

or maybe I'm do it wrong?
[...]
But right now, I have no idea how to limit the execution time

Keep in mind that we don't use the issue tracker for asking questions, it's just for actual bugs or proposals. You framed this as a Language Change Proposal, but to me it seems more like you are actually just asking how to solve a specific design issue you encountered. If that's the case, please see the Questions wiki page; it has a list of good places for asking questions.

Okay @ALTree, forget about my problem. The "or maybe I'm do it wrong?" part is about this proposal, maybe there is a better way other than this one. And the next comment is about the use case.

The point is, I'm proposing a way to terminate long-running C function. Because that is missing part of cgo ecosystem. Go is concurrent programming language but it also allows call C code, and most of C library doesn't handle such of concurrency pattern.

I 100% agree with why is there no goroutine ID, that is why I'm not 100% confident with my own proposal, that is why I need other opinion about this

another design, this is much better I think, because we don't expose anything about go routine

package main

// extern int is_human_existence_pointless();
import "C"

import (
	"fmt"
	"runtime"
	"time"
)

func is_human_existence_pointless() <-chan string {
	c := make(chan string)
	c2 := make(chan string)

	doneCh := runtime.KillableGoroutine(func() {
		answer := int(C.is_human_existence_pointless()) != 0
		if answer {
			c <- "Yes"
		} else {
			c <- "No"
		}
	})
	go func() {
		select {
		case <-time.After(1 * time.Hour):
			close(doneCh)
			c2 <- "Not sure"
		case ans := <-c:
			c2 <- ans
		}
	}()

	return c2
}

func main() {
	fmt.Println("is human existence pointless ?")
	fmt.Println(<-is_human_existence_pointless())
}

I don't see a proposal here. What are you suggesting be changed in the language or standard library?

Sorry, I didn't make it clear.
the proposal is to add func KillableGoroutine(f func()) chan struct{} to runtime package.

I'm still learning into the implementation of goroutine, and maybe I'm not eligible to implement it. But the idea:

func KillableGoroutine(f func()) chan struct{} {
	var thread something // AAAA
	completeCh := make(chan struct{})
	killCh := make(chan struct{})
	go func() {
		LockOSThread() // runtime package already provide this
		thread = currentOSThread() // BBBB
		f()
		close(completeCh) // CCCC
		LockOSThread() // runtime package already provide this
	}()
	go func() {
		select {
		case <-completeCh:
		case <-killCh:
			killOSThread(thread) // DDDD
		}
	}()
	return killCh
}

things that need to figure out:

• type something ... in line with AAAA
• func currentOSThread() something in line with BBBB
• func killOSThread(something) in line with DDDD
• race condition, what will happen when killCh is closed before line with CCCC is executed
• does killing OS thread create memory leak?, what will happen to the rest of the system when we force-kill OS thread?

Are you suggesting that it should be possible to stop a goroutine at any arbitrary point while it is running? That seems complex and difficult. Historically the POSIX threads interface defined a pthread_cancel function, and it's been a source of great complexity and bugs ever since.

What happens if killCh is closed before BBBB is executed?

@ianlancetaylor, I got your point.
I also think the same thing, what about resource that allocated in C is_human_existence_pointless, who is gonna clean-up them.
The only sane way I can think of to this problem is to create another process that call C is_human_existence_pointless and IPC to that process, kill the process when it takes to long, the OS will do the cleaing up.

So, I vote to discard this proposal. Feel free to close this issue.