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 Fri, 25 May 2007 23:34:11 GMT
Andrew Black (JIRA) wrote:
>     [
> 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
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?


View raw message