I've asked this question before about killing a process that uses too much memory, and I've got most of a solution worked out.

However, there is one problem: calculating massive numbers seems to be untouched by the method I'm trying to use. This code below is intended to put a 10 second CPU time limit on the process.

import resource
import os
import signaldef timeRanOut(n, stack):raise SystemExit('ran out of time!')
signal.signal(signal.SIGXCPU, timeRanOut)soft,hard = resource.getrlimit(resource.RLIMIT_CPU)
print(soft,hard)
resource.setrlimit(resource.RLIMIT_CPU, (10, 100))y = 10**(10**10)

What I expect to see when I run this script (on a Unix machine) is this:

-1 -1
ran out of time!

Instead, I get no output. The only way I get output is with Ctrl + C, and I get this if I Ctrl + C after 10 seconds:

^C-1 -1
ran out of time!
CPU time limit exceeded

If I Ctrl + C before 10 seconds, then I have to do it twice, and the console output looks like this:

^C-1 -1
^CTraceback (most recent call last):File "procLimitTest.py", line 18, in <module>y = 10**(10**10)
KeyboardInterrupt

In the course of experimenting and trying to figure this out, I've also put time.sleep(2) between the print and large number calculation. It doesn't seem to have any effect. If I change y = 10**(10**10) to y = 10**10, then the print and sleep statements work as expected. Adding flush=True to the print statement or sys.stdout.flush() after the print statement don't work either.

Why can I not limit CPU time for the calculation of a very large number? How can I fix or at least mitigate this?

Additional information:

Python version: 3.3.5 (default, Jul 22 2014, 18:16:02) \n[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]

Linux information: Linux web455.webfaction.com 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

TLDR: Python precomputes constants in the code. If any very large number is calculated with at least one intermediate step, the process will be CPU time limited.

It took quite a bit of searching, but I have discovered evidence that Python 3 does precompute constant literals that it finds in the code before evaluating anything. One of them is this webpage: A Peephole Optimizer for Python. I've quoted some of it below.

ConstantExpressionEvaluator

This class precomputes a number of constant expressions and stores them in the function's constants list, including obvious binary and unary operations and tuples consisting of just constants. Of particular note is the fact that complex literals are not represented by the compiler as constants but as expressions, so 2+3j appears as

LOAD_CONST n (2) LOAD_CONST m (3j) BINARY_ADD

This class converts those to

LOAD_CONST q (2+3j)

which can result in a fairly large performance boost for code that uses complex constants.

The fact that 2+3j is used as an example very strongly suggests that not only small constants are being precomputed and cached, but also any constant literals in the code. I also found this comment on another Stack Overflow question (Are constant computations cached in Python?):

Note that for Python 3, the peephole optimizer does precompute the 1/3 constant. (CPython specific, of course.) – Mark Dickinson Oct 7 at 19:40

These are supported by the fact that replacing

y = 10**(10**10)

with this also hangs, even though I never call the function!

def f():y = 10**(10**10)

The good news

Luckily for me, I don't have any such giant literal constants in my code. Any computation of such constants will happen later, which can be and is limited by the CPU time limit. I changed

y = 10**(10**10)

to this,

x = 10
print(x)
y = 10**x
print(y)
z = 10**y
print(z)

and got this output, as desired!

-1 -1
10
10000000000
ran out of time!

The moral of the story: Limiting a process by CPU time or memory consumption (or some other method) will work if there is not a large literal constant in the code that Python tries to precompute.