Running golang C-shared library in an OS that uses cooperative scheduling.

[Yonatan Gizachew]

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

[Ian Lance Taylor]

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

[Yonatan Gizachew]

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. 

[Yonatan Gizachew]

This might be trivial, but could you explain me the relationship between the following?

1. value returned by __tls_get_addr

2. runtime.g
3. runtime.g0

4. runtime.mo

5. runtime.m

Thanks:)

On Thursday, September 10, 2020 at 11:31:21 AM UTC+9 Ian Lance Taylor wrote:

[Ian Lance Taylor]

On Wed, Sep 9, 2020 at 7:39 PM Yonatan Gizachew <eme...@gmail.com> wrote:
>
> This might be trivial, but could you explain me the relationship between the following?
> 1. value returned by __tls_get_addr

This is the address of the TLS control block. The exact definition
depends on the architecture. All TLS variables are at some offset
from this value.

> 2. runtime.g

A TLS variable that holds the current goroutine, a pointer to a g struct.

> 3. runtime.g0

A global variable that holds the g struct used for the initial goroutine.

> 4. runtime.m0

A global variable that holds the m struct used for the initial thread.

> 5. runtime.m

gccgo no longer uses this. In earlier releases it was a TLS variable
that holds the current thread, a pointer to an m struct. In current
releases gccgo uses g->m for this.

Ian

[Yonatan Gizachew]

Thank you for the explanation. For example, please have a look at the this bt. 
__tls_get_addr is called after runtime.getg. So, what does __tls_get_addr return at this time, a pointer to runtime.g or runtime.g itself? 

[Yonatan Gizachew]

Also, is there a way to print the values of runtime.g?

[Ian Lance Taylor]

On Wed, Sep 9, 2020 at 11:55 PM Yonatan Gizachew <eme...@gmail.com> wrote:
>
> Thank you for the explanation. For example, please have a look at the this bt.
> __tls_get_addr is called after runtime.getg. So, what does __tls_get_addr return at this time, a pointer to runtime.g or runtime.g itself?

If I recall correctly, __tls_get_addr (which is of course a general
utility that has nothing particularly to do with Go) will return the
address of runtime.g for the thread that calls it.

Ian

> On Thursday, September 10, 2020 at 12:15:04 PM UTC+9 Ian Lance Taylor wrote:
>>
>> On Wed, Sep 9, 2020 at 7:39 PM Yonatan Gizachew <eme...@gmail.com> wrote:
>> >
>> > This might be trivial, but could you explain me the relationship between the following?
>> > 1. value returned by __tls_get_addr
>>
>> This is the address of the TLS control block. The exact definition
>> depends on the architecture. All TLS variables are at some offset
>> from this value.
>>
>> > 2. runtime.g
>>
>> A TLS variable that holds the current goroutine, a pointer to a g struct.
>>
>> > 3. runtime.g0
>>
>> A global variable that holds the g struct used for the initial goroutine.
>>
>> > 4. runtime.m0
>>
>> A global variable that holds the m struct used for the initial thread.
>>
>> > 5. runtime.m
>>
>> gccgo no longer uses this. In earlier releases it was a TLS variable
>> that holds the current thread, a pointer to an m struct. In current
>> releases gccgo uses g->m for this.
>>
>> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20dd490b-f972-4af7-bf4c-f2ab8188c5c1n%40googlegroups.com.

[Ian Lance Taylor]

On Wed, Sep 9, 2020 at 11:58 PM Yonatan Gizachew <eme...@gmail.com> wrote:
>
> Also, is there a way to print the values of runtime.g?

In what sense? Code running the runtime package can just print it.
Or if you run the program under gdb, you should be able to "print
'runtime.g'" (you need the quotes because otherwise gdb will think it
is a structure field reference). At least, gdb works that way on
GNU/Linux, not sure about your operating system.

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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0935d7c3-d2de-49cd-8d25-196b276c5ca9n%40googlegroups.com.

[Yonatan Gizachew]

Thank you!