12:14 <cfbolz> mattip: I think your commit is correct

12:15 <cfbolz> mattip: (I'll add a test for it though)

12:15 <cfbolz> mattip: the problem is that calling threading._after_fork from reinit_threads is that that is too late anyway

12:16 <cfbolz> reinit_threads runs *after* the user-defined fork hooks, destroying any daemon thread introduced by a user defined fork hook again

12:17 <mattip> cool, so the test would be in extra_tests and would make sure deamon threads are not destroyed?

12:17 <cfbolz> yes

12:18 <mattip> nice

12:18 <cfbolz> I can even write it as an app_test in module/posix

12:18 <mattip> those take so long to run. I tried getting all of the stdlib imports out of test_posix2 to speed things up

12:19 <mattip> i.e. using posix instead of os

12:19 <cfbolz> ok

12:21 <cfbolz> done

13:46 <ecarsten> Hi, is there a sensible way to reuse or cache pypy's JIT between runs? I'm working on a compiler that often takes seconds or even minutes to run for real-world programs, so pypy would likely help a lot, but my test suite contains hundreds of 0.5 second compiles of toy programs, and there a switch to pypy degrades performance.

13:49 <ecarsten> I *could* hack some sort of "compiler server" to reuse the same pypy process between runs, but that easily gets brittle, e.g. if global state accidentally leaks between invocations.

13:56 <tumbleweed> I think that's your best bet

14:07 <larstiq_> ecarsten: caching pypy's jit has been mused about, but that would be a bit of a pypy research project. If you want quicker results the "compiler server" seems the way to go (and a common pattern anyway)

14:13 <arigato> or refactor your compiler's code so that it is directly usable as a library, instead of only from the command line. Then you'd also be able to write some unit tests (as opposed to only functional tests)

14:14 <arigato> alternatively, nothing prevents you from invoking your compiler with CPython for most tests, but PyPy in a few of them and when run normally