<qunaibit>
Would it be possible to get a feedback on:
<qunaibit>
it's a simple addition and needed for matplotlib port
<antocuni>
qunaibit: I reviewed it
<qunaibit>
thank you!
<Hodgestar>
:D
<Hodgestar>
fangerer: Re HPyGlobal initialization: What if we made the registration of globals part of HPyModuleDef somehow? That would allow HPy implementations to handle them just during HPyModule_Create.
<fangerer>
Right, that's probably a good idea. Then we would add a `HPyGlobal *globals[]` to `HPyModuleDef` (an array of `HPyGlobal *`) and the first interpreter would allocate the globals and every interpreter would initialize the global with `HPy_NULL`.
<fangerer>
In order to save API calls, we could also allow constant init values in the `HPyModuleDef`. So, basically an array of `{ HPyGlobal *, HPy }`
<antocuni>
this looks like a good idea to me
<steve_s>
but where would you get the HPy value from?
<steve_s>
> we could also allow constant init values in the `HPyModuleDef`. So, basically an array of `{ HPyGlobal *, HPy }
<steve_s>
HPyGlobal as part of `HPyModuleDef` sounds good to me
<fangerer>
You are right, the init values should not be part of the `HPyModuleDef`; I guess that should be a separate part like the type spec params
<steve_s>
Could it be statically allocated array of pointers to HPyGlobal? The usage would be that HPyGlobals would be still global variables, but at the module initialization time the HPy implementation would get a list of (pointers to) HPyGlobals and could initialize them as appropriate. I think this is good, because it would make it clearer that the globals still kind of belong to the module and that there must be a finite number of them
<steve_s>
Still I think this is not going to solve our theoretical problem with multiple engines within one process unless those engines agree on how to initialized and interpret the `_i` inside HPyGlobal
<steve_s>
It seems to me that that is fundamental issue: if we want to use C global variables for the "tokens" for the globally accessible (but still interpreter local) state, then those handles will be shared between all HPy implementations within that process. Module state doesn't have this problem, but it has the problem that one has to pass around additional parameter: the module, which is, however, exactly the indirection that's necessary
<steve_s>
to avoid that issue
<steve_s>
another simplification to make the module state less cumbersome would be to have something like ctx->h_Module for the current module. We discussed that with @fangerer, but I think the conclusion was that it is not clear if we can define what is the current module in all cases?
<fangerer>
IMO, the design should allow it to have `ctx->h_Module`. In cases where it's not clear, it probably needs to be specified manually. E.g. if we provide and API to get an HPy context out of thin air, then we probably need to do that.
<steve_s>
In theory, when you are getting context out of thin air, you must still be running within some extension function, so the current module should be that function. I would disallow getting current context on, e.g., some unrelated non-python thread.
<steve_s>
*should be the module of that function
<fangerer>
Okay, that's ofc possible. Just allow that if there is some function on the stack that already needs a context.
<fangerer>
I was also concerned about the implementation. That means: whenever you invoke an HPy function from Python code, you need to know the module where the function was defined. Is that always quickly possible?
<steve_s>
not sure
pmp-p has quit [Ping timeout: 256 seconds]
<antocuni>
ctx->h_Module is hard IMHO. Suppose I have two modules A and B; I call A.foo() and ctx->h_Module is A, then from foo() I call B.bar() at the C level (bypassing python): what should ctx->h_Module be inside B.bar()?
pmp-p has joined #hpy
pmp-p has quit [Ping timeout: 272 seconds]
pmp-p has joined #hpy
pmp-p has quit [Ping timeout: 272 seconds]
pmp-p has joined #hpy
cfbolz has quit [Read error: Connection reset by peer]