On 7/20/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:

>>
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>> .
>>
>> How do you plan to handle CPU-hogs? Stuff like execution of a
>> gigantic integer multiplication.
>
>
> I don't.  =)  Protecting the CPU is damn hard to do in any form of
> portable fashion.  And even getting it to work on an OS you do know
> the details of leads to probably an interrupt  implementation and
> that doesn't sound fun.

I think the trick used by the safe_eval recipe (a separate thread which
interrupts the script through thread.interrupt_main()) shows that, in most
cases, it's possible to make sure that an embedded script does not take too
long to execute. Do you agree that this usage case ("allow me to timeout an
embedded script") is something which would be a very good start in the right
direction?

Probably.  I just don't feel like worrying about it right now.  =)

Now, I wonder, in a restricted execution environment such as that depicted
in your document, how many different ways are there to make the Python
interpreter enter a long calcolation loop which does not release the GIL? I
can think of bignum*bignum, bignum**bignum or similar mathematical
operations, but there are really a few. If we could make those release the
GIL (or poll some kind of watchdog used to abort them, pretty much like they
normally poll CTRL+C), then the same trick used by the recipe could be used.

Well, any work that does most of its calculation within C code and that does not touch base with the interpreter on a semi-regular basis would need to relesae the GIL.

-Brett
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to