stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <>
Subject Re: [jira] Commented: (STDCXX-426) infinite loop in exec utility
Date Wed, 30 May 2007 22:13:32 GMT
Greetings Martin

With regards to the documentation issue for the kill logic in exec.cpp, 
I'll work on improving that, and also verifying that the exit conditions 
for the cleanup loop is what is desired.

The only options I see for processing the result log in a more efficient 
manner are seeking to a fixed distance from the end and reading forward, 
or seeking to the end and reading in reverse to locate the beginning of 
the summary section.  The former method has been tried before (per my 
comment) which leaves us with the later.  If anyone has alternatives, 
I'd be interested in knowing what they are.

I'm not certain, but I think I'll have time during this week to work on 
this change.

--Andrew Black

Martin Sebor wrote:
> Andrew Black (JIRA) wrote:
>> The second note regards the mechanics used to process the test suite 
>> output.  At this time, the parser uses a simple finite state machine 
>> (FSM) to search through the output file, byte by byte, to locate the 
>> output summary, starting at the beginning of the file.  However, this 
>> processing method was changed in 
>> and 
>> .  Prior to the 
>> later commit, the script was first seek()ing to a location near the 
>> end of the file prior to beginning the search.  The problem with this 
>> method is that some tests produce output after the summary totals have 
>> been printed out.  The earlier change adjusted the seek location to a 
>> point earlier in the file to accommodate this trailing output, but no 
>> guarantees can be made about the amount of trailing information.
>> A possibly 'better' way to perform this search would be to seek to the 
>> end of the file, then parse backwards, looking for a marker that 
>> indicates you've reached the beginning of the summary, then read 
>> forwards to parse the summary itself.
> I'm not sure about seeking but I am quite sure that reading
> the file one character at a time isn't the most efficient
> way of doing it, especially given that file we're reading
> can be arbitrarily big (as in this case). So what's your
> plan? Do you intend to implement something more efficient
> and robust or what?
> Martin

View raw message