2013-03-06 15:09:39 +01:00
|
|
|
timeout-interrupt
|
|
|
|
=================
|
2013-03-06 11:58:38 +01:00
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
Works like ruby's timeout, but interrupts *every call*, also syscalls, which blocks the hole ruby-process.
|
2013-03-06 11:58:38 +01:00
|
|
|
|
2013-03-06 15:09:39 +01:00
|
|
|
It uses POSIX's alarm and traps ALRM-signals.
|
2013-03-06 11:58:38 +01:00
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
Known limitations bacause of alarm and ALRM are, that you can not use alarm or trap ALRM in the same time.
|
|
|
|
|
2013-03-06 15:09:39 +01:00
|
|
|
|
2013-03-07 12:30:07 +01:00
|
|
|
Scopes
|
|
|
|
======
|
|
|
|
|
|
|
|
If you need scopes with inner and outer time outs, you should know:
|
|
|
|
|
|
|
|
The first timed out Timeout will be raised:
|
|
|
|
|
|
|
|
include TimeoutInterrupt
|
|
|
|
timeout(1) { # Will be raised
|
|
|
|
timeout(10) { sleep 2 } # Will not be raised
|
|
|
|
}
|
|
|
|
|
|
|
|
If you want to know, which was raised, you need custom exceptions:
|
|
|
|
|
|
|
|
class CustomErrorWillBeRaised <Exception
|
|
|
|
end
|
2022-03-24 12:45:07 +01:00
|
|
|
class CustomErrorNotRaised <Exception
|
2013-03-07 12:30:07 +01:00
|
|
|
end
|
|
|
|
include TimeoutInterrupt
|
|
|
|
timeout( 1, CustomErrorWillBeRaised) { # Will be raised again
|
2022-03-24 12:45:07 +01:00
|
|
|
timeout( 10, CustomErrorNotRaised) { sleep 2 } # Will not be raised
|
2013-03-07 12:30:07 +01:00
|
|
|
}
|
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
|
2013-03-07 12:30:07 +01:00
|
|
|
Problems
|
|
|
|
========
|
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
Memory-Leaks and missing clean up
|
|
|
|
---------------------------------
|
2013-03-07 12:30:07 +01:00
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
Syscalls can allocate memory.
|
|
|
|
If you interrupt a syscall, which then cannot free his allocations, it will result in a memory leak.
|
|
|
|
If it opens a file, while it reads, a time out occurs, the file will not automatically be closed.
|
2013-03-07 12:30:07 +01:00
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
So, you should only use it, if your process will die after interrupt or if you are sure, that your call never allocate memory or opens a file.
|
|
|
|
You could also publish informations about opened files, that it could be cleaned up later.
|
2013-03-07 12:30:07 +01:00
|
|
|
|
|
|
|
Every time, a process dies, all his memory will be freed and every file will be closed, so let your process die and you should be safe.
|
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
|
2013-03-07 12:30:07 +01:00
|
|
|
Exception-handling
|
|
|
|
------------------
|
|
|
|
|
|
|
|
Timeouts can break your exception-handling! You should not handling exception while you wait for a timeout:
|
|
|
|
|
|
|
|
include TimeoutInterrupt
|
|
|
|
timeout(1) {
|
|
|
|
begin
|
|
|
|
transaction_begin
|
|
|
|
do_something
|
|
|
|
ensure
|
|
|
|
clean_up
|
|
|
|
transaction_end
|
|
|
|
end
|
|
|
|
}
|
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
Same happens, if clean\_up will raise an exception, so handle it in the same way.
|
2013-03-07 12:30:07 +01:00
|
|
|
|
|
|
|
And same problem you have with ruby's `Timeout.timeout`.
|
2013-03-06 11:58:38 +01:00
|
|
|
|
2013-03-06 15:09:39 +01:00
|
|
|
Copyleft
|
|
|
|
=========
|
2013-03-06 11:58:38 +01:00
|
|
|
|
2022-03-24 12:45:07 +01:00
|
|
|
Copyright (c) 2021 Denis Knauf. See LICENSE.txt for further details.
|