Golang supports LockOSThread()
to make current goroutine exclusively tied to current OS thread, and it can also UnlockOSThread()
.
Are there any use cases that benefit from this feature?
Golang supports LockOSThread()
to make current goroutine exclusively tied to current OS thread, and it can also UnlockOSThread()
.
Are there any use cases that benefit from this feature?
With the Go threading model, calls to C code, assembler code, or blocking system calls occur in the same thread as the calling Go code, which is managed by the Go runtime scheduler.
The os.LockOSThread()
mechanism is mostly useful when Go has to interface with some foreign library (a C library for instance). It guarantees that several successive calls to this library will be done in the same thread.
This is interesting in several situations:
a number of graphic libraries (OS X Cocoa, OpenGL, SDL, ...) require all the calls to be done on a specific thread (or the main thread in some cases).
some foreign libraries are based on thread local storage (TLS) facilities. They store some context in a data structure attached to the thread. Or some functions of the API provide results whose memory lifecycle is attached to the thread. This concept is used in both Windows and Unix-like systems. A typical example is the errno global variable commonly used in C libraries to store error codes. On systems supporting multi-threading, errno is generally defined as a thread-local variable.
more generally, some foreign libraries may use a thread identifier to index/manage internal resources.