Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <46577273.90808@roguewave.com>
Date: Fri, 25 May 2007 17:34:11 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-426) infinite loop in exec utility
References: <21599157.1180110616653.JavaMail.jira@brutus>
In-Reply-To: <21599157.1180110616653.JavaMail.jira@brutus>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Black (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/STDCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499145 ] 
> 
> Andrew Black commented on STDCXX-426:
> -------------------------------------
> 
> I have a couple more notes on this issue that came out of the collaborative analysis Martin and I made of this issue last night.
> 
> The first note regards the signal that is sent after the child process has terminated.  This signal is being sent to the child process group.  The purpose is to ensure the termination of grandchild processes.  The logic of the code that does this cleanup isn't particularly clear, so I need to add some commentary to it.
> 
> Martin also suggested making a possible change to this section of the code.  That change was to check if the process group exists (by sending signal 0 to it) prior to sending signals to it.  I believe I considered this when crafting the loop, but discarded it.  Part of my reason for doing so was because one of the exit conditions for the loop is when the kill signal fails to send a message to the group.  My perception of the benefit of doing things this way is that it reduces the number of system calls made when grandchild processes need to be harvested.

Well, as it is, we send the signal unnecessarily in the vast
majority of cases anyway since most groups consist of exactly
one process and the process is gone by the time we reach this
point. So we're not saving any system calls one way or the
other (not that there's any need to save them, it's not like
we could run out ;-) But I suppose it doesn't really make
a difference whether we send signal 0 to check if the group
still exists, followed by SIGHUP when it does, or go straight
to SIGHUP regardless. It would be nice to document our decision
in the code, though.

> 
> 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 http://svn.apache.org/viewvc?view=rev&revision=515332 and http://svn.apache.org/viewvc?view=rev&revision=516188 .  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