with timeout(...):

[Diez B. Roggisch]

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

 

[Nick Craig-Wood]

Early versions of Scheme had a neat solution to this problem.
You could run a function with a limited amount of "fuel". When the
"fuel" ran out, the call returned with a closure. You could
run the closure again and pick up from where the function had been
interrupted, or just discard the closure.

That sounds like a really nice concept. That would enable you to make
long running stuff yield without threads too.

I wonder if it is possible in python...

 

[Nick Craig-Wood]

I second this (or third or whatever if my post is slow).
It is tremendously useful to start something and to be told it has timed
out by a call, rather than to have to unblock the i/o yourself and
to "busy-loop" to see if its successful.

Yes, exactly!

And from what I can see the select functionality is not much
different from busy looping...

Conceptually it is no different. In practice your process goes to
sleep until the OS wakes it up again with more data so it is much more
CPU efficient (and possibly lower latency) than busy waiting.