David Marchand <david.march...@redhat.com> writes: > On Tue, Apr 2, 2019 at 11:37 AM Bruce Richardson <bruce.richard...@intel.com> > wrote: > > On Mon, Apr 01, 2019 at 09:29:51PM +0200, David Marchand wrote: > > On Mon, Apr 1, 2019 at 9:28 PM Aaron Conole <acon...@redhat.com> wrote: > > > > > David Marchand <david.march...@redhat.com> writes: > > > > I tried using meson/ninja for the tests, something that bothered me is > > > that I can't interrupt the tests. > > > > I had to kill manually, meson, ninja and I had some leftover dpdk-test > > > processes (maybe due to some ^Z I > > > > hit...). > > > > Is this expected ? > > > > > > Certainly not by me. I usually let everything complete, though (which > > > takes a looong time if I run the full suite). > > > > > > > This is quite frustrating when testing "before" and "after" each patch. > > > > > > Agreed. :-/ > > > > > > I'll have to try it out to see what's happening. Does it only happen > > > with this series? I'd be surprised, but possibly I introduced some > error. > > > > > > > Nop, I got this even before your first patch. > > > > Is this meson related or related to the auto test binary in DPDK. I know > traditionally I've found the test binary rather difficult to kill, but I'd > like to be sure that the meson infrastructure itself isn't making it worse. > > Hard to tell, I would have to retest and investigate, unless Aaron went > further than me.
I did some investigation with this. At least I don't see any lingering process from meson, but it does take time for the tests to die when I hit CTRL-C, and I get a warning - I found this related bug: https://github.com/mesonbuild/meson/issues/2281 I guess it could be some kind of interplay between the way meson kills tests? Looking at the commit that eventually 'closes' the bug, they merely set a flag rather than pass a kill signal down, so I guess it's probably never going to be immediate.
