incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Farid Zaripov <Far...@kyiv.vdiweb.com>
Subject RE: testsuite process helpers [PATCH]
Date Wed, 02 Aug 2006 16:52:24 GMT
  > -----Original Message-----
 > From: Martin Sebor [mailto:sebor@roguewave.com]
 > Sent: Friday, July 28, 2006 4:02 AM
 > To: stdcxx-dev@incubator.apache.org
 > Subject: Re: testsuite process helpers (was: RE: string
 > methods thread safety)
[...]

   Martin, I have been updated the files rw_process.h, process.cpp and 
0.process.cpp. The new files are attached.

   ChangeLog:
     * rw_process.h (rw_pid_t): The type long changed to intptr_t
     (on Windows) and pid_t (on other platforms).
     (rw_process_error_report_mode): New variable to enable/disable
     rw_error() outputs within defined functions.
     (rw_wait_pid): Added the timeout parameter.
     (rw_process_kill): New function to kill the specified process.
     * process.cpp: Ditto.
     * 0.process.cpp: New test exercising the rw_process_create(),
     rw_process_kill() and rw_waitpid() functions.


 > I think it's important to exercise this functionality. We'll
 > need to come up with a way to silence the errors in these
 > tests. Maybe via some global variable or something like that.

   I added the extern variable to the rw_process.h to handle this.

// if == 0 - report about errors using rw_error() (default)
// if != 0 - do not report about errors
_TEST_EXPORT extern int
rw_process_error_report_mode;

   Maybe will be better to implement a function 
rw_set_process_error_report_mode() which sets a new value and returns 
the previous one?


 > There is another problem with the test: we cannot assume that
 > 1234 (or any other number we pick out of a hat) is an invalid
 > process id.

   To resolve this I used the pid from succeeded test of the 
rw_process_create() instead of 1234.


 > If there is a process with that pid our test might never
 > finish (or fail with a false negative). Which brings up
 > another point: we need to be able to kill the (child) process
 > in case it hangs, and we need to exercise the ability to
 > correctly report the signal the child process exited with, or
 > more generally, its exit status.
   To resolve this I added the additional parameter --timeout for the 
test (the default timeout is 5 seconds).


 > Also, as a general comment on the test, it helps to give each
 > test function a descriptive name (rather than test1, test2,
 > etc. It's also nice to print out some information (using
 > rw_info()) about what's being tested.

   Done.


Farid.

Mime
View raw message