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.
