Closed namandixit closed 4 years ago
afaik, it's intended to be use as a thread's "default co_thread". since it can be used as an actual co_thread, it needs to be an array to store the required thread state.
But the library doesn't seem to be storing anything in it, just using its pointer (which is unique for each thread) as a co_thread
when we are NOT using a stack/coroutine created by co_create
.
Also, what do you mean by "thread state"?
The pointer can be used in other library functions as if it was a co_thread
.
For example, if it was passed to co_switch
, the new executing thread state would be read from the buffer.
If you follow the logic within the library internally uses it to store the non-co_thread thread state. (Hint: co_swap cannot have a nullptr argument and must swap the thread state with something)
Oh wait, I think I get it: it's storing the registers in the array, instead of on the stack for the default thread of execution (created without using co-create
). Is that right? (That's sneaky!!)
Yes indeed!
Thanks, I'm gonna close this one. Near's code is a tour de force :P
It seems that it is used only to get a unique address when calling
co_active
from a non-coroutine function. Why is it an array then, and not just a thread-local global variable?