On Sat, Jul 08, 2006 at 03:44:55PM -0700, Scott Wang wrote: > Thanks Paul! > > (1) Yes, we do send SIGKILL (9) to kill the parent > process even the child processes are still running and > our purpose is to have a clean kill from "root", so, > do you think send SIGKILL (2) will be better? or, we > could consider to send SIGKILL (2) to kill all the > child processes before send SIGKILL (2) to kill parent > process, do you think this may help? > > (2) "Maybe you could send it something a little nicer > which might allow to process to clean up.", any more > detail suggestion and example will be appreciated!
I'm not quite sure what your environment looks like, so I can only give some general suggestions at best. If you can avoid signals completely, I would try to do that. Maybe you have some other method of IPC going on that you could use to use to send a "kill yourself" command. Singals in perl used not to be safe, that is they could lead to corruption or crashes. Since 5.8 they have been safe (providing you haven't explicitly made them unsafe). (Hopefully you are not using 5.6.) So if you can send a signal which can be caught, and then set up a signal handler which cleans up (if necessary) and then exists the program, that should allow things to work better. You might like to consider USR1 or USR2 for this, if you are not already using them. Or you might prefer TERM. In any case, you should ensure that it is a signal which can be caught, which is not the case with KILL. > (3) We might also consider to give some sleep time > before destroy the test object, which causes process > killing and cleaning up, but, is there a way we can > know Devel::Cover has doen its work to write data? > > (4) "Devel::Cover does its work in the very last END > block.", does this mean that Devel::Cover will not > write data until the main test process run to its end? Sleeping, then killing won't work. Although Devel::Cover collects data the entire time a program is running (unless you turn it off at some point), the data will not be saved until its END block is run. This will normally be the very last END block. This means that unless you let the program run to completion the coverage data will not be fully saved. You might hinder this process by calling _exit, calling exec, sending SIGKILL or doing anything else that stops normal completion of the program. > For example, a perl test script loads the perl module > that is under testing and excise the functions in that > module, sometime the test script needs use "system" to > call some other perl scripts (that also is under > testing), Devel::Cover will not write data until the > main test script reach its end point or exit? Correct. But the scripts you are calling with system will not have any coverage data collected unless you have arranged for that in some way. And if you do that, the coverage data for those scripts will be written as soon as the scripts exit. > (5) Is there a way we can tell which data files (under > structure folder?) have been corrupted? Just try reading them with the retrieve method from Storable. Better yet, send me patches for Devel::Cover::DB::validate_db and Devel::Cover::DB::is_valid to do something more than just check that one file exists there ;-) (Those methods should probably be merged too.) (And sorry they are not already written. I suspect something a little more robust there might have saved you a bit of pain.) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
