search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.38k stars 17.7k forks source link

proposal: thread-local or per-cpu storage support #22476

Closed idealvin closed 7 years ago

idealvin commented 7 years ago

Use case: Write a service using Thrift framework. Thrift may have several logical threads or routines to handle request from clients.

In my implementation of the service, all the thrift logical threads will finally call my function: function do_something() And the function do_something will read data from redis server. With thread-local support, I can create a connection to the redis server for each thread.

This is very useful and I don't know how to implement it without thread-local storage support. So please consider about it. Thanks.

dlsniper commented 7 years ago

This is very useful and I don't know how to implement it without thread-local storage support. So please consider about it. Thanks.

The problem seems to be the implementation, not the language. Please reconsider your problem and refactor the implementation by avoiding any prior form of knowledge about TLS. At that point the implementation will reveal itself as a simple, obvious, solution based on existing concepts and tools.

tl;dr: don't Write C++/Java in Go, write Go in Go.

idealvin commented 7 years ago

@dlsniper Yeah, I have just turned from C++ to Go recently and not familiar with Go.

In my case, it seems that I have no better solution with Thrift as the logical threads are created and scheduled by Thrift itself.

Is there some existing solutions for my case? Thanks very much.

ALTree commented 7 years ago

Dup of the old #8281

dlsniper commented 7 years ago

As this is not a Go issue I think we should move it in one of the following mediums:

I'm sure you'll find a way to solve this.

I believe this should be closed.

idealvin commented 7 years ago

Last question. Thanks. Why not provide a function to get the current routine id in go?

dlsniper commented 7 years ago

Because in 4.5 years of writing concurrent Go I've never needed such functionality and, for the most part, neither will the vast majority of the programmers. There are extensive, similar, threads out there proving over and over again that this is not a needed feature in order to write concurrent applications. Please use the available search solutions to find them in the above mentioned spaces.

To ask the similar question: Given solutions exist outside of this particular design, why not use a different algorithm instead of requiring a change of the standard library to allow for a very specific implementation to exist?

idealvin commented 7 years ago

@dlsniper Yes, I think I have found a solution like this:

I write a new redis client with n(cpu num) routines and one connection per routine. The n routines will handle redis tasks together. I just send a task to the redis client and wait for the result.

Thanks.

By the way, your golang-plugin for ideaide seems not work on pycharm 2017.2 now. I really like this plugin!

dlsniper commented 7 years ago

By the way, your golang-plugin for ideaide seems not work on pycharm 2017.2 now. I really like this plugin!

Please use Gogland (dedicated Go IDE) or IntelliJ IDEA Ultimate. For additional information ping me on Gophers Slack or Twitter.

idealvin commented 7 years ago

@dlsniper ok, thanks!