William, Am 16.06.20 um 11:27 schrieb William Lallemand: >> Actually we must always remember that while convenient, VTest's >> primary goal is to test a proxy by synchronizing the two sides (which >> is what basically no other testing tool can reliably do). If we want >> to run deeper tests on other process-oriented behaviors, it can make >> sense to rely on other tools. For example vtest is not the best suited >> to testing command line or process stability. It has no process >> management, can leak background processes and needs to wait for a >> timeout to detect a crash. >> >> My point above is that as long as *proxy* tests are compatible with >> stopping using SIGUSR1 I think I'd be fine with the change. But if >> doing this actually results in more pain to test the proxy features, >> I'd rather stay away from this and switch to a distinct test series >> for this. That's where I'd draw the line. >> > > I think that's a good idea but It will probably because it will let us > test the deinit() with all the diversity of configuration we have in the > reg-tests.
Yes, that was the intention behind my suggestion. The reg-tests already test various configurations during regular operation. It should be easy enough to also test a clean deinit() for those configurations by using SIGUSR1 instead of SIGINT. I don't expect any major issues with the normal testing operation, because the deinit() happens after the regular proxy tests finished. And a buggy deinit() still is a bug. > But I also agree with Willy and we should be careful about the > consequences of this change. If there is too much changes to handle it > may be painful to do it before the 2.2 release. > I'd definitely postpone changing anything about VTest past 2.2. Any bugs found using that will be backported anyway. So nothing really lost by waiting for the release. Best regards Tim Düsterhus
