<fangerer>
Good morning! Don't forget: we will have the HPy dev call in 55 minutes.
<antocuni>
mattip: I'm not very familiar with cpytext's bytes/unicode but in principle yes
<antocuni>
the difference is that we would like the allocation to be compatible with the JIT
<antocuni>
because the W_HPyObjects are also normal applevel objects of course
<antocuni>
ideally, we would like to be able to allocate them in the nursery (but then we need pinning as long as the handle is open in C land)
<antocuni>
an easier but still suboptimal alternative is to allocate them directly in non-movable memory
<ronan>
antocuni: I'll merge hpy-refactor-exceptions. I looked at exception checking but I think it needs to be fixed inside rpython
<antocuni>
+1
<antocuni>
what do you mean by "exception checking" precisely?
<ronan>
the unnecessary checks for RPython exceptions when you call a C function
<antocuni>
ah ok
<antocuni>
I thought it was "just" a matter of putting the right hints, similar to what you get when declaring an llexternal manually
<antocuni>
I'm fine to merge it as is, but maybe write a comment so that we don't forget the issue?
krono has quit []
<ronan>
no, AFAICT you can't put a hint on a pointer, only on an RPython function
krono has joined #hpy
<antocuni>
does it mean that we check for exceptions every time we invoke a random C function? It sounds weird
<ronan>
I think we do, actually
<antocuni>
ouch
<ronan>
cpyext and llexternal create wrappers, where exception checking is disabled
<ronan>
but I think we end up checking around the wrapper, always
<antocuni>
so if we have an external C function which returns NULL, we always check for RPyErr_Occurred() also?
<ronan>
I think so, one way or the other
<ronan>
the wrappers actually do things, usually, so checking for exceptions might actually be required
<ronan>
but I don't see a way to disable the check even when the wrapper is trivial
<antocuni>
like for example, what happens when you call rlib.rtime.c_time()?
<antocuni>
it is declared as _nowrapper=True, releasegil=False
<arigato>
either way, I think that checking RPyErr_Occurred() costs extremely little actual time
<antocuni>
I confirm that by looking at the generated C code and following what happens with gdb, calling rtime.c_time is translated in a straight call to the C level time function
<antocuni>
arigato: sure, but why pay the cost if we can avoid it?
<antocuni>
also, I fear that it might be a source of bugs
<antocuni>
like, I have an RPython exception set and I call an hpy function, which succeeds but return a value which is incorrectly interpreted as "exception raised" by RPython. What happens in this case?
<arigato>
you shouldn't be able to execute any RPython code when an RPython exception is set
<arigato>
the only way I can think to manage to do it is, precisely, to call a C function which calls back RPython but somehow convince RPython not to check for exceptions after the call to the C function
<antocuni>
yes, I think you are right
<arigato>
then the exception would be randomly raised a bit later, or maybe possibly be overwritten
<antocuni>
but I still think that "let's do the wrong thing because it has little performance penalty" is still worse than "let's to the right thing which by the way is also maybe faster"
<ronan>
antocuni: I don't think it's ever wrong to check for an exception in RPython
<arigato>
I'm just saying that IMHO the "maybe faster" in this sentence might be "never actually faster". I don't have an opinion on whether you want to try to do it anyway
<antocuni>
and I am worried that by losing 0.1% here and 0.5% we will end up in the same land as cpyext, which is also full of "this costs so little that we can forget" things
<antocuni>
that said, I think that the time we are spending in such a discussion is more than the time which needs to be spent to actually fix it, so I'll shut up :)
<ronan>
antocuni: I think cpyext suffers more from "it's expensive but we'll do it anyway because it's convenient"
<ronan>
anyway, I missed something: you can actually avoid the check for C functions, but not for function pointers
<antocuni>
ah, so maybe it's a missing hint on the lltype of the function pointer itself?
<ronan>
well, the hint wouldn't do anything
<ronan>
but yes, in principle we could add a hint and refactor rpython/translator/backendopt/graphanalyze.py a bit
<ronan>
though really, we should refactor low-level rpython to have a notion of external call separate from {in,}direct_calls
<antocuni>
indeed, this looks saner than what we have now