with timeout(...):

[Nick Craig-Wood]

irstas at gmail.com <irstas at gmail.com> wrote:
>  On Mar 26, 3:16 pm, "Diez B. Roggisch" <d... at nospam.web.de> wrote:
> > But to make that work reliably, it has to be ensured that no sideeffects
> > occur while being in some_long_running_stuff. which doesn't only extend to
> > python itself, but also external modules and systems (file writing, network
> > communications...). Which can't be done, unless you use a time-machine.
> 
>  Hey hey, isn't the Python mantra that we're all adults here?

Yes the timeout could happen at any time, but at a defined moment in
the python bytecode interpreters life so it wouldn't mess up its
internal state.

>  It'd be the programmers responsibility to use only code that has no
>  side effects. I certainly can ensure that no side-effects occur in
>  the following code: 1+2. I didn't even need a time machine to do
>  that :P Or the primitive could be implemented so that Python throws
>  a TimeoutException at the earliest opportunity. Then one could
>  write except-blocks which deal with rolling back any undesirable
>  side effects. (I'm not saying such timeout feature could be
>  implemented in Python, but it could be made by modifying the
>  CPython implementation)

I don't think timeouts would be any more difficult that using threads.

It is impossible to implement reliably at the moment though because it
is impossible to kill one thread from another thread.  There is a
ctypes hack to do it, which sort of works...  It needs some core
support I think.

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