From: Brett van de Sande <bvds@as...> - 2010-04-02 16:32:21
>> I imagine that there are use cases for both, so I envisioned some kind
>> of timeout designator, like (:RUN-TIME . 5.0) vs. (:REAL-TIME . 5.0)
>> where just 5.0 would be tantamount to (:REAL-TIME . 5.0).
>Unless someone comes forward with such a case, I'm skeptical. The only
>cases where I've seen timeouts is with realtime constraints.
Let me vote for the runtime constraint: that is exactly what
I need in my case. I am using timeouts to catch any hung code
(infinite loops etc) rather than just slowness. If my server
gets overloaded, using real time for timouts causes things to
degrade rather ungracefully.
Also, I would rather the term "wall-clock-time" instead of "real-time".
Ande maybe "cpu-time" instead of "run-time".
>Additionally, we don't have portable ways to track run-time per thread
>-- and timing out locally based on the whole-process run-time seems
>like an even stranger use-case.
Agreed. But on a server with several processes running, process time
is still closer to what I want than wall clock time.