> On Aug. 17, 2015, 6:22 p.m., Ben Mahler wrote: > > src/linux/perf.cpp, line 199 > > <https://reviews.apache.org/r/37424/diff/1/?file=1038974#file1038974line199> > > > > We may want to update this to become killtree in a separate patch? Or > > are we guaranteed that perf will clean up child processes? If so, that > > warrants a comment :)
This is guaranteed to work because of the process group setup by setupChild. I will add an appropriate comment. > On Aug. 17, 2015, 6:22 p.m., Ben Mahler wrote: > > src/linux/perf.cpp, lines 304-312 > > <https://reviews.apache.org/r/37424/diff/1/?file=1038974#file1038974line304> > > > > How about we just use the discard semantics that are already set up > > inside initialize()? If a discard is requested, we will terminate. > > > > This leaves the composition in the caller, which we usually prefer > > (rather than pushing in timeout logic to all libraries, it's easier to > > provide discard semantics and have the caller discard when it's no longer > > interested). > > > > So the idea here is now your callers use a .after() which does a > > discard(). I'll move the timeout to the calling sites where required. - Paul ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37424/#review95606 ----------------------------------------------------------- On Aug. 13, 2015, 12:29 a.m., Paul Brett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37424/ > ----------------------------------------------------------- > > (Updated Aug. 13, 2015, 12:29 a.m.) > > > Review request for mesos and Ben Mahler. > > > Repository: mesos > > > Description > ------- > > Timeout the perf future if the process does not complete. > > > Diffs > ----- > > src/linux/perf.cpp cb1a13d0b1754a50f0121bfda522056ff8c3e3c8 > > Diff: https://reviews.apache.org/r/37424/diff/ > > > Testing > ------- > > sudo make check > > > Thanks, > > Paul Brett > >
