[go-nuts] Re: thread local storage of C library from go application
Thanks Tamas for elaborating. So if i understand, the C library will see the calls as if application is single threaded, i mean a single goroutine/thread issues C calls. ofcourse go library can manage to distribute to different gorotuines/threads based on the API type . will give more thoughts on it, Regards, On Wednesday, April 22, 2020 at 3:27:06 PM UTC+5:30, Tamás Gulácsi wrote: > > > 2020. április 22., szerda 10:04:37 UTC+2 időpontban Pavan a következőt > írta: >> >> >> Hi, >> putting the lockosthread from library cant match with goroutines TLS and >> its complex on handling goroutines exit and mapping all the GO api's (C >> fns if any with them ) called by applications to same OS thread . >> >> ofcourse applications cant call lockosthread too as they are not aware of >> the GO API internals of c functions usage. >> >> > In your library, spawn a goroutine, which > 1. calls runtime.LockOSThread, > 2. and then listens to commands on a channel, > 3. calls the C library, > 4. responds on a channel given beside the command > in a loop. > > And hide all this, and create the API that translates direct calls to such > command sending on the command channel, > waiting for the answer and returning it. > > The essence is that the C-calling goroutine must be on the same thread > where it has started. > This is to allow the C library to work, which assumes a lot about its > calling environment when storing data in thread-local storage > > -- 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/974a91b7-da44-49c8-af4a-3c8b5147b25d%40googlegroups.com.
[go-nuts] Re: thread local storage of C library from go application
2020. április 22., szerda 10:04:37 UTC+2 időpontban Pavan a következőt írta: > > > Hi, > putting the lockosthread from library cant match with goroutines TLS and > its complex on handling goroutines exit and mapping all the GO api's (C > fns if any with them ) called by applications to same OS thread . > > ofcourse applications cant call lockosthread too as they are not aware of > the GO API internals of c functions usage. > > In your library, spawn a goroutine, which 1. calls runtime.LockOSThread, 2. and then listens to commands on a channel, 3. calls the C library, 4. responds on a channel given beside the command in a loop. And hide all this, and create the API that translates direct calls to such command sending on the command channel, waiting for the answer and returning it. The essence is that the C-calling goroutine must be on the same thread where it has started. This is to allow the C library to work, which assumes a lot about its calling environment when storing data in thread-local storage -- 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/b02c6a34-12c8-409e-a7e4-e4213d7321e6%40googlegroups.com.
[go-nuts] Re: thread local storage of C library from go application
Hi, putting the lockosthread from library cant match with goroutines TLS and its complex on handling goroutines exit and mapping all the GO api's (C fns if any with them ) called by applications to same OS thread . ofcourse applications cant call lockosthread too as they are not aware of the GO API internals of c functions usage. I think this complexity will stay if the C library is called from GO, please suggest if i missed anything. Regards, On Wednesday, April 22, 2020 at 12:29:29 PM UTC+5:30, Pavan wrote: > > Thanks Tamas , I see earlier discussion too on this > https://groups.google.com/forum/#!topic/golang-nuts/8Tdb-aCeYFY. > As I understand, the GO library should lock the current go routine to > thread, if it involves C functions with TLS data and unlock after > completing such C functions . > > > Regards, > > > > On Tuesday, April 21, 2020 at 11:12:50 PM UTC+5:30, Tamás Gulácsi wrote: >> >> Lock C-calling goroutines to their threads with runtime LockOSThread and >> communicate with them through channels. > > -- 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/da9e330a-20f7-4047-bf2c-8ff1f10fc284%40googlegroups.com.
[go-nuts] Re: thread local storage of C library from go application
Thanks Tamas , I see earlier discussion too on this https://groups.google.com/forum/#!topic/golang-nuts/8Tdb-aCeYFY. As I understand, the GO library should lock the current go routine to thread, if it involves C functions with TLS data and unlock after completing such C functions . Regards, On Tuesday, April 21, 2020 at 11:12:50 PM UTC+5:30, Tamás Gulácsi wrote: > > Lock C-calling goroutines to their threads with runtime LockOSThread and > communicate with them through channels. -- 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/c9b61cc5-8e5c-4dff-bc32-e3de4d833460%40googlegroups.com.
