On 7/20/06, Giovanni Bajo <rasky at develer.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060720/d60aea40/attachment.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4