15:22 <Corbin> I know it's unlikely, but is there a portable way in RPython to customize NaN behavior? Every NaN check is generating a guard, and unrolled loops with NaN checks are causing an explosion of paths.

15:22 <Corbin> This is largely my fault for unrolling the loop in the first place, and I'm trying to fix that. But it would be nice if I could just get NaNs transformed to 0.0 or something like that.

15:23 <cfbolz> Corbin: nope, no such thing yet

15:24 <Corbin> Oh well. Maybe you'll find this funny: https://bpa.st/MZVQ

15:25 <Corbin> This takes about 4 seconds without NaN checks. It should run in realtime on a mid-class GPU, but emitting GPU code is such a headache and I'm not there yet.

21:33 <mattip> I think I am stumbling across a CPython behaviour difference with signals

21:35 <mattip> deep inside OpenSSL, a SIGPIPE signal is triggered, which on CPython turns into a BrokenPipeError

21:36 <mattip> it seems PyPy does not do that conversion, in spite of a line in the PyPy ssl code that says "signals are checked frequently in the bytecode dispatch loop"

21:37 <mattip> at least at the point in the code where CPython catches the exception, PyPy does not stop

21:39 <mattip> maybe because of cffi?

21:39 <mattip> or because it is in a thread?

21:42 <cfbolz> mattip: who triggers the signal?

21:42 <cfbolz> ah, because the socket was closed

21:43 <mattip> openblas tries to read from a "file", which is closed

21:44 <mattip> I ran the test under gdb, which will stop on signals. Then I told it to ignore the stopping with "> handle SIGPIPE nostop"

21:44 <mattip> but it still prints the signals, as well as threads stopping and starting

21:45 <mattip> so I see the thread start, the signal emitted, and then the thread stops.

21:45 <mattip> I can even see the BrokenPipeError exception being caught, and can print there

21:45 <mattip> PyPy never raises the BrokenPipeError exception

21:45 <mattip> so the thread does not die, and the test hangs

21:54 <mattip> hmm, in CPython this is not automatic, it is part of the ssl.shutdown code?

22:00 <mattip> apparently the signal is a false flag. The problem is elsewhere

22:06 <cfbolz> sounds all complicated

22:06 <cfbolz> mattip: I am impressed you managed to do this advanced gdb stuff

22:06 <mattip> it really is only two threads, but I get confused going from python code to c code

22:07 <mattip> and trying to compare _ssl.c with our cffi code

22:07 <mattip> the "happy path" works fine, it is the tests checking the dark corners of the errors that is broken

22:08 <mattip> on openssl3

22:08 <cfbolz> right :-(

22:08 <cfbolz> mattip: is the signal getting delivered to a different thread on pypy?

22:08 <mattip> signals are only ever delivered to the main thread on both pypy and cpython

22:10 <mattip> now I am thinking that a read is returning -1 on PyPy and 0 on CPython, but maybe that is a false flag too

23:41 <mattip> hang on, mabe this is all due to the error codes changing between versions

23:41 <mattip> https://github.com/python/cpython/pull/25300