-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems in the timeout utility #20
Comments
ok, edited. You can assign me to it. |
About "point 1":I'm archiving this here, so that you can already take a look, because I have to go to sleep, soon. I tested this on CW, but it should look like this in the file of the framework (not tested yet in this context) def timeout(sec):
def wrapper(func):
from multiprocessing import Process, Value
msg = 'Should not throw any exceptions inside timeout'
def wrapped(finished):
try:
func()
finished.value = 1.0
except BaseException as e:
finished.value = 1.0
fail("{}: {}".format(msg or "Unexpected exception", repr(e)))
finished = Value('d',0.0)
# needed to know if the process crashed without any "feedback" and before any
# assertion has been done in the wrapped function or the wrapper (happens if
# the heap memory explodes)
process = Process(target=wrapped, args=(finished,))
process.start()
process.join(sec)
if process.is_alive():
fail('Exceeded time limit of {:.3f} seconds'.format(sec))
process.terminate()
process.join()
elif not finished.value:
fail('Something went wrong: the process running your function crashed without raising errors')
return wrapper I'm actually wondering about the message in the last This is working so far: |
oops, I closed it by mistake... |
I'm playing with the idea of allowing to wrap describe/it blocks with the timeout utility, this morning. Very bad idea, so far: I cannot get consistent behaviours. Surely I messed up my logic, but I cannot find where. Dropping the idea, for now. |
ok, there are actually several problems about it.
Context
So far, it handles properly:
But it has two problems in its current state:
describe/it
) of the assertions done inside the timeout utility is ambiguous for one, and even worse, may be different depending on what the function passed by the user to the decorator is doing.Developping point 1:
Used that way:
leads to
floodRAM
displaying no assertion result at all, meaning this is a "win" for the user if all other tests are passing.Developping point 2:
Current state of the decorator:
So, imagining the following possible uses:
This leads to assertions that can be done outside of a
@test.it
block, which is what we are currently fighting against...For now, the documentation tells nothing about that (about "how to use or not the timeout decorator", I mean)
Suggestions
Resolving point 1
I already found a way to handle this. I still have to test the behaviour in different situations to check that it works as expected.
The idea is to pass a
Value
to theProcess
, so that this value is updated only if the decorated function doesn't raise/crash. This value is examined afterward at the end of the wrapper to check that the process actually updated itResolving point 2
Here I'd need some guidance... I see mostly 3 ways out of this:
@test.it
block. This way, nothing to change in the code about that.test.it
block(s). Then we can add a newit
block at the end of the wrapper to get the correct level.it
block or not. I sort of like the idea, and dislike it at the same time... :/What would you prefere?
Corollary:
I blieve that the tests checking the framework (
python-test-framework/tests/fixtures/
) need an update too, to test for all those scenarii (except maybe the buffer limit error?)final question?
That may be the occasion to add the option asked by Voile (see #4). Even if it' effectively doesn't seem that useful (see FArekkusu's answer), I like the idea of giiving more flexibility to the user.
Go or no go?
The text was updated successfully, but these errors were encountered: