<mattip>
1) LeavePythonExecution/ReenterPythonExecution need some GIL handling (started tackling this in the hpy_gil branch)
<mattip>
2) no Err_WriteUnraisable
<mattip>
3) no EXPORT_GLOBAL
<mattip>
4) some formatting of support.DefaultExtensionTemplate.INIT_TEMPLATE
<mattip>
5) some formatting of _debug.get_open_handles exception
<mattip>
so we are getting close ...
<mattip>
(5) done
glyph has quit [Quit: End of line.]
glyph has joined #pypy
<mattip>
(4) done
<mattip>
(3) needs HPy_Global_Store and HPy_Global_Load
<mattip>
where should we put the object? Into the _hpy_universal.state.State ?
<antocuni>
mattip: what is "tne object" in your last question?
glyph has quit [Quit: End of line.]
glyph has joined #pypy
glyph has quit [Client Quit]
glyph has joined #pypy
<mattip>
the thing we are storing globally
<mattip>
(2) is done, now "just" missing some GIL handling and Global_Store, Global_load
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
<mattip>
cpyext has a "gil=" kwarg to the API functions, maybe I can duplicate some of that for HPy
<antocuni>
so, the idea of HPyGlobal is to have some sort of long-lived handles which can be stored as static global C variables
<antocuni>
as an extension writer, you have to declare a global HPyGlobal variable, and list it HPyModuleDef.globals = ...
<antocuni>
from the pypy point of view, what we want is to assign an unique ID to each HPyGlobal, which will probably be an index inside an RPython list
<antocuni>
this RPython list should probably be stored as a field of _hpy_universal.state.State
<antocuni>
the difference w.r.t. normal handles is HPy handles are supposed to be short lived, while HPyGlobal are long lived (and thus e.g. the debug mode doesn't complain if they "leak")