with timeout(...):

[Diez B. Roggisch]

Nick Craig-Wood schrieb:
> Diez B. Roggisch <deets at nospam.web.de> 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