robert wrote: > Ben Finney wrote: > > robert <[EMAIL PROTECTED]> writes: > > > >> Carl Banks wrote: > >>> 2. Consider whether you're unwittingly trying to cover up a bug. > >>> ISTM no matter how problematic the input is, you should at least > >>> be able to make progress on it. Are you getting this error > >>> because, say, you're not incrementing a counter somewhere, and > >>> thus recalling a function with the same arguments again? > >> the "bug" comes in from the I/O input. > > > > If a program doesn't gracefully deal with bad input, that's a bug in > > the program. You should be designing your input handler so that it > > will do something helpful (even if that's to stop immediately with an > > informative error message) in the event of bad input, rather than > > allowing that bad data to send your program into an endless loop. > > > Yet that detection is what the asked alg should do. > Example: When a HTML-(content)-relaying sends > you around in a circle through a complex handler chain.
You might find some engineering inspiration in CherryPy's InternalRedirect handler [1], which simply raises an error if you visit the same state twice. Another option is to periodically check a timeout, which CherryPy does via an Engine.monitor thread [2] (that runs Response.check_timeout [3]). Note that either approach requires some alteration to the code being inspected. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] [1] http://www.cherrypy.org/browser/tags/cherrypy-3.0.0RC1/cherrypy/_cpwsgi.py [2] http://www.cherrypy.org/browser/tags/cherrypy-3.0.0RC1/cherrypy/_cpengine.py#L240 [3] http://www.cherrypy.org/browser/tags/cherrypy-3.0.0RC1/cherrypy/_cprequest.py#L565 -- http://mail.python.org/mailman/listinfo/python-list