with timeout(...):

[Nick Craig-Wood]

Hendrik van Rooyen <mail at microcorp.co.za> wrote:
>  so Diez is probably right that the way to go is to put the timer in the
>  python interpreter loop, as its the only thing around that you could 
>  more or less trust to run all the time.
> 
>  But then it will not read as nice as Nick's wish, but more like this:
> 
>  id = setup_callback(error_routine, timeout_in_milliseconds)
>  long_running_stuff_that_can_block_on_IO(foo, bar, baz)
>  cancel_callback(id)
>  print "Hooray it worked !! "
>  sys.exit()
> 
>  def error_routine():
>      print "toughies it took too long - your chocolate is toast"
>      attempt_at_recovery_or_explanation(foo, bar, baz)
> 
>  Much more ugly.

I could live with that!

It could be made to work I'm sure by getting the interpreter to check
for timeouts every few hundred bytecodes (like it does for thread
switching).

>  But would be useful to be able to do without messing with
>  threads and GUI and imports. 
>  Could be hard to implement as the interpreter would have 
>  to be assured of getting control back periodically, so a 
>  ticker interrupt routine is called for - begins to sound more 
>  like a kernel function to me.  
>  Isn't there something available that could be got at via ctypes?

I think if we aren't executing python bytecodes (ie are blocked in the
kernel or running in some C extension) then we shouldn't try to
interrupt.  It may be possible - under unix you'd send a signal -
which python would act upon next time it got control back to the
interpreter, but I don't think it would buy us anything except a whole
host of problems!

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick