Nick Craig-Wood schrieb: > Diez B. Roggisch <[EMAIL PROTECTED]> wrote: >>> I beleive the convention is when calling an OS function which might >>> block the global interpreter lock is dropped, thus allowing other >>> python bytecode to run. >> >> So what? That doesn't help you, as you are single-threaded here. The >> released lock won't prevent the called C-code from taking as long as it >> wants. |And there is nothing you can do about that. > > I'm assuming that the timeout function is running in a thread...
I wouldn't assume that - it could be a python on a platform without threads. I really don't think that your idea is worth the effort. If there is something that can be safely interrupted at any given point in time - which is the exception, not the rule - then one can "code around" that missing feature, by spawning a subprocess python, using pyro to communicate, and terminate it. I've done so before. Some people here said "we're adults, we make sure our code will be safely interruptable". But first of all, even adults make errors, and even more important: most of the time such a feature is wanted, it's about limiting some scripts that come from an untrusted source - like user-written plugins. Such a feature would encourage people to use it in such cases, but not stand up for the nastiness it may provoke. Diez -- http://mail.python.org/mailman/listinfo/python-list