Bug 212323
| Summary: | Go: allow FuncLauncher to modify current thread context | ||
|---|---|---|---|
| Product: | Tools | Reporter: | lmb |
| Component: | libcap | Assignee: | Tools/Libcap default virtual assignee (tools_libcap) |
| Status: | RESOLVED ANSWERED | ||
| Severity: | enhancement | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | any | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
I just found https://bugzilla.kernel.org/show_bug.cgi?id=211919. From https://bugzilla.kernel.org/show_bug.cgi?id=211919#c12 > I guess I am still open to changes that make it more useful, but I'm not > really open to requiring users of libcap/cap to manually do > runtime.LockOSThread() to use its API. Fair enough! Feel free to close this issue in that case. https://bugzilla.kernel.org/show_bug.cgi?id=211919#c23 > I think this would mean we can't allow launchers to do syscalls in parallel, which will ultimately cause things to unnecessarily serialize on kernel calls. As it is the code allows two launchers to launch mostly in parallel. Does this mean I could invoke FuncLauncher, block in the callback and then invoke another Launcher? (This would still prevent modifying the whole process, but I can live with that.) I'm now using several FuncLaunchers to accomplish the same goal. Closing this issue. |
I just discovered FuncLauncher(fn func(interface{}) error) *Launcher which is a great addition to the toolkit. I'd like to use it as follows: func SetupNetworkNamespace() int { go func() { runtime.LockOSThread() cap.FuncLauncher(func() error { // acquire cap.SYS_ADMIN return syscall.Unshare(CLONE_NEWNET) }) // further initialization // block until the caller is done with the netns <-quit }() // return fd to newly created network namespace here. } As you can see I already have to play games with the Go threads for my own purpose and the unshare needs to happen on the thread that I lock. I can't block inside of the FuncLauncher callback since that blocks all other FuncLaunchers. Slightly OT: I think the interface{} argument to fn isn't necessary. In Go it's easy to create an anonymous closure that captures variables in a type safe way. It reminds me a bit of void* ctx in C?