A little musing on the infinite loop issue...

It seems that, for the most part, each layout manager turns predominately to its 
children LMs to see what they're up to.  As a result, it's not easy to spot at a high 
level (ala the PageLayoutManager) that some singular element is holding the entire 
works up.  In the case of one of my stripped-down infinite loop tests, it's a single 
string of text that is constantly spilling off the page.  The only indication I can 
seem to locate in code that its TextLayoutManager is not making progress in laying it 
out is that, at every time its getNextBreakPoss() method is called, it can poll itself 
to see what character in its internal array it's starting the positioning at, and 
discover that, call after call, it's making no progress and trying to constantly 
reposition the same string starting at the same character number...every time.

I'm suspecting that, in general, these "low men on the totem pole" are the only LMs in 
any position to spot the abject lack of progress that characterizes the infinite loop. 
 At that point, they need to send a notice up the line that they suspect an infinite 

Now, here's the hard part as I see it- our users are defining page sequences of 
variable size, and so it just might take many iterations in general to finally reach a 
page with room for the object in question.  Would the correct policy in this case be 
for there to be a callback process from the low-level LMs to send messages up the line 
back to their PageLMs so that they can keep an eye on the page sequencing and, after 
all possible pages have been tried, give up?

Or would an acceptable solution to the maintenance branch (which is a dead-end branch) 
just be to let the cycle run for, say, 20 iterations and, at that time, assume an 
infinite loop and throw an Exception to break the cycle?

-----Original Message-----
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 3:56 AM
Subject: Re: Page breaking infinite loop

On Wed, 2002-09-18 at 20:38, Christian Geisert wrote:
> Go for it! (don't forget to assign the bug to yourself)
> By the way .. any comments from you (as a classloader expert ;-)
> on the following bug:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255

If you want to fix that bug why not simply do a null check and maybe try
the system class loader.

> Christian

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to