cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
DylanYoung has quit [Remote host closed the connection]
_whitelogger has joined #pypy
dddddd has joined #pypy
<arigo>
yay, I finally managed to figure out a Linux hack to have proper "caches", by which I mean data that an application would like to cache as long as there is memory but not swap out
<arigo>
it's a hack: have a FUSE file system that doesn't actually store any data, but that tells the kernel "you can cache what I have"
<arigo>
reads from "files" either succeed from the kernel cache, or the FUSE module gives an EIO
<arigo>
a useful write-only file system :-)
dddddd has quit [Ping timeout: 256 seconds]
kipras`away has quit [Ping timeout: 256 seconds]
lritter has joined #pypy
jvesely has quit [Remote host closed the connection]
<njs>
in particular, the report is that control-C can interrupt the main thread when it's blocked in a system call, and I don't understand how that could be possible
<njs>
(also as a secondary issue -- pypy ships with cffi included, right? does it ship metadata to tell pip that it's included already? because the user also reports that our dependencies were pulling in cffi and trying to build it from source, which I thought was unnecessary on pypy)
<arigo>
njs: yes, pypy ships with cffi included with metadata too. No clue what's going on for your user
<njs>
arigo: ok, cool, that part I know how to investigate further :-) any idea about the signal handling thing?
<njs>
in CPython, on Windows, if the main thread is blocked in a syscall when a signal arrives, then the python-level signal handler doesn't get a chance to execute at all until the syscall returns...
<arigo>
we didn't spend much effort on supporting windows with pypy3, so I have no clue why pypy3 seems to be better than cpython in that respect
<njs>
well AFAIK it's actually impossible to do better than CPython while using the CPython semantics :-) I was wondering if you might run the signal handler off the main thread or something like htat
<arigo>
we don't create a background thread automatically
<arigo>
even if we did, if a background thread does "raise KeyboardInterrupt" it will at most interrupt this background thread only
<njs>
so windows automatically creates a background thread to run C-level signal handlers
<arigo>
the cffi re-installation is probably because trio or something depending on it has a "cffi>=1.14" dependency
<njs>
and I thought potentially that could create some weirdness? at the time the C-level signal handler runs, our main thread has released the GIL, so if that background thread captured the interpreter state and temporarily "became" the main thread, it could produce this outcome. (In particular, our Python-level signal handler is clever enough to wake up the main thread.)
<njs>
arigo: ah ha, yes, it does, because we need the fix for the getwinerror memory leak :-)
<arigo>
on both pypy and cpython, the C-level signal handler doesn't do anything more than ask for the python-level handler to run at the next opportunity in the main thread
<arigo>
afaik the python-level handler can only run in the main thread
<njs>
huh, mysterious
lritter has quit [Quit: Leaving]
<njs>
btw, what happens if you do try to pip install a newer cffi into pypy? does it work?
<mattip>
AFAICT it happily installs a new version to site-packages, but the internal version is imported since it appears first on sys.path
<mattip>
at least that is my impression installing 1.14.0 into pypy2.7-v7.1.1
CrazyPython has quit [Read error: Connection reset by peer]