PhotonLibOS
PhotonLibOS copied to clipboard
alibaba
Do coroutines support local storage (like thread_local)?
May I know the reason you want this feature? Is that you want better performance when sharing resource among coroutines within a unique cpu core?
BTW, we used to migrate some thread-based projects to coroutines with Photon, for example, rocksdb.
No matter of std::thread, std::mutex, std::condition_variable and so on, most of the components are very easy to transform to Photon's equivalents, but thread_local is still the thing we are uncertain how to deal with.
If you have met the same problem, we would like to hear your situation.
@jiangdongzi Photo supports a very limited form of coroutine local storage, via:
void* thread_get_local();
void thread_set_local(void* local);
BTW, we used to migrate some thread-based projects to coroutines with Photon, for example, rocksdb. No matter of std::thread, std::mutex, std::condition_variable and so on, most of the components are very easy to transform to Photon's equivalents, but
thread_localis still the thing we are uncertain how to deal with. If you have met the same problem, we would like to hear your situation.
In our business, we hash user to specified thread via uid, every business thread has its own specified data. While coroutine maybe transfered from std::threadA to std::threadB, this will result in problem.
In our business, we hash user to specified thread via uid, every business thread has its own specified data. While coroutine maybe transfered from std::threadA to std::threadB, this will result in problem.
Coroutines are not necessarily transferred from one std::thread to another, unless you instruct photon to do so. It is possible that you can still use thread_local variables?
In our business, we hash user to specified thread via uid, every business thread has its own specified data. While coroutine maybe transfered from std::threadA to std::threadB, this will result in problem.
Coroutines are not necessarily transferred from one std::thread to another, unless you instruct photon to do so. It is possible that you can still use thread_local variables?
Yeah, if this is the behaviour, there is no problem. But do you have plans of auto transferring coroutines? Such as std::threadA is busy, and std::threadB is idle.
But do you have plans of auto transferring coroutines? Such as std::threadA is busy, and std::threadB is idle.
Yes, we'll support automatic load balancing of threads (coroutines) among vCPUs (std::threads) by work-stealing. Perhaps within this year.