Hendrik van Rooyen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list