While working on issue#12157 [http://bugs.python.org/issue12157], I needed a function that make sure that an operation will not hang forever, for this reason i have create this helper function that support the context manager protocol and accept a timeout as an argument and raise an IOError if the operation didn't terminate before that timeout.

It's a little bit more complicated than that:- signals and threads don't mix well together- this will make syscalls fail with EINTR- the old SIGALRM handler is lost- etcIn short, don't use signals.I'm not sure there's a reliable way to write such a general-purpose wrapper (usually one can use select() with a timeout or spawn a subprocess and use communicate's timeout to achieve this kind of things).In your use case (issue#12157), I think that letting the test block is fine, since:- there's no easy way to add a timeout (but you could spawn a new interpreter and use communicate with a timeout if you really wanted to)- it will be caught by the faulthandler module- a test killed by faulthandler's timeout is more interesting to fix that a "common" failed test ;-)

Thanks for the instructive feedback :)I totally agree i guess there is a lot of issues that i didn't think of :-(, my first thinking was to use "Pool.join" timeout argument but it was removed in 3.2 (by the way i didn't find the issue or the rational that lead to this change).And now that i know about "faulthandler" module i guess that will make also my life easier :), i will rewrite the patch in the issue#12157 to not use any *fancy* way to check if it will hang.cheers,

alarm() is one possible implementation, but Charles-François listed some drawbacks.You can also use resource.setrlimit(RLIMIT_CPU), but the timeout is the CPU time (e.g. you cannot stop a sleep) and it is not portable (e.g. resource is not available on Windows).Another possible implementation is a thread. faulthandler uses an "hidden" thread (implemented in C): a thread ignoring all signals using pthread_sigmask. Python threads are not reliable for a timeout because of the GIL, and it is not easy to "interrupt" another thread from the "timeout" thread. For example, you cannot (easily) raise an exception in another thread.> I'm not sure there's a reliable way to write such a general-purpose> wrapperI agree, but it doesn't mean that it is not possible :-)I think that you should try to implement in C a thread ignoring all signals. It becomes more complex when you have to implement the "interrupt the current thread" (current thread, or maybe the thread using the operation_timeout context manager?) part.I suppose that you will have to use low-level "tricks" and you will have to experiment your tool on different platform.You should start this project outside CPython (as a third party module), and then ask for an integration when your work is well tested. You have to know that a module "dies" when it enters CPython: you have to wait something like 18 months to modify it, so you have to be sure that your code is "correct" ;-)

Oh, there is another possible implementation: use a subprocess. But if the timeout is implemented using a subprocess, the syntax cannot be:with timeout(5):   do_something()It should be something like:timeout(5, """if 1:   import os, sys   ...   do_something()   ...   sys.exit(0)""")Some tests are already doing that manually.

Closing, since it's hard to write correctly, and apparently not that useful.