cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<_aegis_>
njs: yeah I know... trying to minimize latency as this is used for realtime input. mostly trying to prevent a user from accidentally locking up on infinite loop
<_aegis_>
might try pthread_kill
<_aegis_>
for now I'd probably rather restart the whole app on lockup than run user code in a subprocess
<arigato>
pthread_kill is probably a bad idea, because I think pypy won't clear the GC stack information for the dead thread and it will crash at the next GC. not completely sure though
<arigato>
_aegis_: I don't see any solution that is portable between cpython and pypy
marr has joined #pypy
lesshaste has quit [Remote host closed the connection]
jaffachief has joined #pypy
energizer has quit [Ping timeout: 256 seconds]
lazka has quit [Quit: Leaving]
lazka has joined #pypy
fdb has joined #pypy
inhahe__ has joined #pypy
inhahe_ has quit [Ping timeout: 248 seconds]
<fdb>
Hello, i would report that on the download page there are links to pypy2-v5.10.1 but files does not exist.
<ronan>
mattip: I can't import pandas on py3.5, Cython complains that datetime.time has the wrong size, try recompiling. Expected 24, got 40. Any clue?
marky1991 has quit [Ping timeout: 260 seconds]
marky1991 has joined #pypy
<mattip>
ronan: let me take a look
illume has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jaffachief has joined #pypy
jcea has quit [Quit: jcea]
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jaffachief has joined #pypy
jaffachief has quit [Client Quit]
jaffachief has joined #pypy
jaffachief has quit [Client Quit]
jaffachief has joined #pypy
jaffachief has quit [Client Quit]
ronan has quit [Ping timeout: 248 seconds]
lazka has joined #pypy
<_aegis_>
arigato: I am completely fine doing a pypy-only solution for now, even if it requires me to modify the interpreter
<_aegis_>
as I'm shipping this in an app w/ its own libpypy
<_aegis_>
also with pthread_kill I figured I'd send a SIGINT and hope it caused a KeyboardInterrupt in that thread
jcea has joined #pypy
<_aegis_>
ah, I guess pthread_kill only supports two signals
<_aegis_>
tgkill maybe
<arigato>
no, a SIGINT is always handled by the main thread
<arigato>
all signals are
<arigato>
ah no, we ported something from pypy-stm back to the mainline pypy:
<arigato>
you can say "with __pypy__.thread.signals_enabled:"
<arigato>
then all the code inside the "with" is run with signals enabled, even if it's running in a non-main thread
<arigato>
in this situation, I think that pressing Ctrl-C on the keyboard would send a KeyboardInterrupt in a random thread, either the main one or one with signals_enabled
<arigato>
pthread_kill() should work, but you'll need cffi to call that
<nanonyme>
arigato, is it good that it rolls up in a random thread? :/
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
lazka has quit [Quit: Leaving]
zmt01 has quit [Quit: Leaving]
zmt00 has joined #pypy
jcea has quit [Quit: jcea]
ronan has joined #pypy
tbodt has joined #pypy
<arigato>
nanonyme: no, that's just an example. If you use pthread_kill() it should be directed to a specific thread
<arigato>
(in the Ctrl-C case, it has more chances to land in a thread that takes a lot of CPU, so it's a weighted randomness :-)
<nanonyme>
I still think the entire concept is a bit scary. I had before always been under the impression that Python mandated main thread handles signals
<njs>
_aegis_: note that there are lots of fun race conditions to worry about when trying to signal a thread, like if the thread has just exited the `with __pypy__.thread.signals_enabled` block when you send the signal, then it'll end up being handled in the main thread (and maybe killing it instead)