(1) Is it impossible for an interpreter to switch between trusted and untrusted modes? This is probably a reasonable restriction, but worth calling out loudly in the docs.
(2) For the APIs returning an int, it wasn't clear what that int would be, other than NULL => interpreter is trusted. I'm not sure that NULL is even always the best answer when the interpreter is trusted. For example, if I called PyXXX_AllowFile, I want to know whether the file is now allowed; I don't really care that it is allowed because the interpreter is trusted anyhow. (3) Should PyXXX_Trusted have a variant that takes group/type/string, meaning "Am I allowed to do *this*?", rather than having to special-case the "You can do anything" case? (4) For capped resources, there needs to be a way to tell what that cap is, and how much is left. (Logically, this provides "how much is already used", which is already a frequently requested feature for memory.) One use of untrusted interpreters is to stop runaway processes. For example, it might always be OK to add 4M memory, so long as it has been at least 10 seconds since the last request. This requires the controller to know what the current setting is. Caps and current usage should also be available (though read-only) from python; it is quite sensible to spill some cache when getting too close to your memory limit. (5) I think file creation/writing should be capped rather than binary; it is reasonable to say "You can create a single temp file up to 4K" or "You can create files, but not more than 20Meg total". (6) Given your expectation of one interpreter per web page, interpreters will have to be very lightweight. This might be the real answer to the CPU limiting -- just run each restricted interpreter as its own "thread" (possibly not an OS-level thread), and let the scheduler switch it out. -jJ _______________________________________________ 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