Robot Framework Version: Robot Framework 2.1.2 (Python 2.6.2 on win32)

I have a keyword that is cpu-bound, it uses the difflib module to compare two files (130MB each). When i dont set the timeout on the testcase this test completes in about three minutes. When I set a timeout it never completes. I might be hitting the problem described in [1] and [2].

I have attached MindlessLibrary.py one keyword that spins mindlessly and a test case file defining two testcases. The first test case has no test timeout set and will finish in approximately 50 seconds. The second test case sets a test timeout of 4 minutes. This test will hit the test timeout.

I am logging this issue here so that we know about the problem.

Instead of running the keywords in a separate thread in Python we could run them in a child process using the multiprocessing module.

[1] http://www.dabeaz.com/python/GIL.pdf [2] http://www.dabeaz.com/blog/2010/01/python-gil-visualized.html

Unfortunately we need to support Python 2.5 and multiprocessing module is available only from 2.6 onwards. I checked the links and based on what I read, there is nothing we can do to fix the problem. Anyway the issue is valid and we need to document it.

Thanks for really good problem analysis.

This needs to be documented in user guide where timeouts are documented.

Added documentation to User Guide r2783 and r2784.

This issue is included in RF 2.5 alpha 1.

Comment deleted

I tested the mindlesslibrary on my computer. "No Timeout" test case finished in 1 min,"With Test Timeout" test case takes about 25mins, sometimes more.one time it took about 80mins.

I add a new file robotprocess.py under robot/utils, and changed the file robot/running/timeouts.py. using multiprocessing module,only support python 2.6 and higher. if the python version is lower than 2.6, it will use robotthread.py, otherwise,it will use robotprocess.py.

Thanks for the patch!

Unfortunately we can not apply it for the following reasons.

Unit tests don't pass when the patch is applied.

Also I think it is not enough to just change things to work with processes as there is no shared state with the processes (threads share state) -- there is no code for sharing robot or the test cases etc.

Thus I don't think that you can make for example a test case with timeout with this mechanism.

Apparently another reason timeouts are so slow in Robot is that our thread stopping hack is based on sys.settrace:

"""Other non-solutions include using sys.settrace in the thread. In addition to making the thread code horribly slow, this will also fail to work when the thread calls into C functions."""

http://eli.thegreenplace.net/2011/08/22/how-not-to-set-a-timeout-on-a-computation-in-python

Issue 871 should fix the slowdown in most cases.

Removing Type-Documentation in favor of Type-Defect and Type-Enhancement to ease migrating issues to GitHub.