Is "loader_life_support " possible to be somehow coroutine-safe?

[Readm]

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?

Thanks.

[victor3d]

I encountered this case too

[laramiel]

Loader life support comes into play when there's an implicit conversion when calling type_caster::load().
The simplified version is that when python calls into C++ the python object needs to be reference counted for the lifetime of the c++ call. loader life support creates a "parallel" stack in the per-thread variable (each frame with a loader life support object is linked to a parent frame).

I'm not sure how this interacts with what you describe. Maybe write a test case which fails and which you expect to succeed?