You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all, I am implementing a C++ coroutine library that allows calling some Python functions. However, I found that it may trigger an error message ‘loader_life_support: internal error’ when switching between coroutines. This seems to be a problem with loader_life_support. I noticed that there is a fix (#3237) @laramiel
that makes it thread-safe by using a thread-local structure (seems only record the stack top?) to maintain all variables. However, this may not be compatible with the coroutine model. For example, consider the following sequence:
Function A starts, Function A yields,
Function B starts, Function B yields,
Function A resumes, Function A returns,
Function B resumes, Function B returns.
Therefore, I am considering whether loader_life_support can be changed to support coroutine lifecycle in some way. But I am not sure:
1 why it is currently implemented as a thread-local key-value. Under what circumstances will the content it guards go wrong?
2 If it is only for the lifecycle of temporary variables, it seems that it can also be done without relying on thread local.
3 If I make changes, what is the best way to test its functional completeness?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all, I am implementing a C++ coroutine library that allows calling some Python functions. However, I found that it may trigger an error message ‘loader_life_support: internal error’ when switching between coroutines. This seems to be a problem with loader_life_support. I noticed that there is a fix (#3237) @laramiel
that makes it thread-safe by using a thread-local structure (seems only record the stack top?) to maintain all variables. However, this may not be compatible with the coroutine model. For example, consider the following sequence:
Therefore, I am considering whether loader_life_support can be changed to support coroutine lifecycle in some way. But I am not sure:
1 why it is currently implemented as a thread-local key-value. Under what circumstances will the content it guards go wrong?
2 If it is only for the lifecycle of temporary variables, it seems that it can also be done without relying on thread local.
3 If I make changes, what is the best way to test its functional completeness?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions