I see. Thanks for the explanation. It basically use function interposition to redirect Pthreads function calls made from golang to Pth. In that case a thread runs until it reaches a pth yield instruction, which transfers control to the scheduler and activates another available thread.
On Thursday, September 10, 2020 at 11:31:21 AM UTC+9 Ian Lance Taylor wrote: > On Wed, Sep 9, 2020 at 7:26 PM Yonatan Gizachew <eme...@gmail.com> wrote: > > > > Is there any known problems that could appear when we run golang > C-shared libraries in an OS that uses a non-preemptive scheduling > mechanism. I am experiencing some problems related to TLS (more > specifically runtime.m0 and runtime.g0). > > FYI - the C-shared library was built suing the gccgo compiler as: > > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > Note that runtime.m0 and runtime.g0 are not themselves TLS variables. > runtime.g is a TLS variable. > > As gccgo has not been tested on your platform, any number of problems > are possible. How does your OS handle scheduling non-preemptively? > Only schedule on system calls? I think that could work with typical > Go programs, although it could longer GC pauses with gccgo. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/02b65d23-4a5b-4282-8d12-566ef90b5363n%40googlegroups.com.