embedded python - cancel "while 1: pass"

[Tim Peters]

[Warren Postma]
> Okay, I have a worse case than WHILE 1: PASS
>
> How about uninterruptible C code called via python, such as this:
>
> print 2L ** 2L ** 256
>
> I've let this run for 15 minutes and it didn't complete. There is no
> apparent way to abort it either, as it spends its time in
> long_mult and the Python scheduler doesn't even run.

See Steven's reply:  Python does check for keyboard interrupt during
long_mult, so you have a platform or embedding problem here.  I had no
trouble interrupting it, for example, under Win98SE from a DOS box Python
session.  This won't work, though, if you're running under IDLE (Tk grabs
the keyboard events first, but Tk doesn't get a chance to run so long as
Python is running, so Python never sees the keyboard interrupt despite that
it's checking for it, because Tk never gets a chance to pass the interrupt
on to Python).

> It must complete eventually.
> Any idea how long long_mult and long_pow will take to
> complete this?

They won't.  But that's because they'll eventually die with a MemoryError:
the number of bits in the true result requires about 78 decimal digits to
express.  If you've got a gigabyte of RAM, the number of bits you have only
takes about 10 decimal digits to express.  So how long it takes to die on
your box depends on how much real and virtual memory you have -- if you're
lucky, it will die about 3 days after your disk starts grinding itself to
dust because of all the VM thrashing <wink>.

> ...
> In that case, I think I'm still stuck with the Three Finger
> Salute method (reboot).

Since that's a Windowsism, I hope you know you can kill Python from the Task
Manager, instead of rebooting.  Windows was carefully designed to let you
recover from anything <wink>.