Am 04.03.2012 23:53, schrieb Steven D'Aprano: > Armin Rigo wrote: >> Hi Mark, >> >> On Sun, Mar 4, 2012 at 18:34, Mark Shannon <mark at hotpy.org> wrote: >>> You can't solve the too much time, without solving the halting problem, >> >> Not sure what you mean by that. It seems to me that it's particularly >> easy to do in a roughly portable way, with alarm() for example on all >> UNIXes. > > What time should you set the alarm for? How much time is enough before > you decide that a piece of code is taking too long? > > The halting problem is not that you can't breaking out of an infinite > loop, but that you can't *in general* decide when you are in an infinite > loop. > > I think that Mark's point is that you can't, in general, tell when you > are in a "too much time" attack (or bug) that needs to be broken out of > rather than just a legitimately long calculation which will terminate if > you wait just a little longer. This is getting off-topic, but you can *certainly* solve the "too much time" problem without solving the halting problem. The "too much time" problem typically has a subjective, local, application-specific specification. Therefore, the "too much time" problem is *easily* solved with timeouts. Too much is just too much, even if it would eventually complete with a useful result. I'd say that a single request should not take more than 20 seconds, else it's too much. It must be less than 2 seconds for interactive use, and less than 1s if you get more than 100 requests per second. If these numbers sound arbitrary to you: they are. They are still useful to me. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4