incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [jira] Commented: (STDCXX-426) infinite loop in exec utility
Date Wed, 30 May 2007 22:34:12 GMT
Andrew Black wrote:
> 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.

Okay, thanks for the update!

> 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.

Seeking might sound like the most efficient way of doing it
but I'm not sure it's the most robust approach (is the stream
guaranteed to be seekable?) I still think that reading the
file one big chunk at a time and then scanning that chunk
would be just as fast in most cases and safer. Not just
because the stream may not be seekable but also because
there might be an arbitrary amount of junk anywhere in
the file, including at the end, following the summary.


> 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