> On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp, lines > > 110-113 > > <https://reviews.apache.org/r/11849/diff/1/?file=304306#file304306line110> > > > > You only add one process to 'stopped'/'visited' right in one iteration > > right? > > > > Why are you repeatedly sending SIGSTOP to the same process? > > > > Also, I highly recommend adding a verbose option to this function. It > > has proved invaluable to us when using/debugging the erstwhile killtree > > script.
This only sends SIGSTOP to each process once. If someone calls killtree with SIGSTOP then killtree behaves strangely. Perhaps I should guard against that, thoughts? > On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp, line 79 > > <https://reviews.apache.org/r/11849/diff/1/?file=304306#file304306line79> > > > > I think it makes more sense to call 'stopped' set as 'visited' per > > typical graph algo terminology. I was a bit confused because i was equating > > stopped with processing getting a SIGSTOP. The nice thing about stopped is it clearly captures when each process has been sent SIGSTOP. I initially went with a generic BFS implementation in terms of terminology and insertion into 'visited' but it's not as clear I found. - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11849/#review21824 ----------------------------------------------------------- On June 12, 2013, 7:49 p.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11849/ > ----------------------------------------------------------- > > (Updated June 12, 2013, 7:49 p.m.) > > > Review request for mesos, Benjamin Hindman and Vinod Kone. > > > Description > ------- > > For how killtree will be used, see the killtree.sh script in mesos. > > This version is actually more robust than killtree.sh, as it first stops the > entire tree, _then_ issues the signal. > Currently, killtree.sh stops, signals, and continues each process in > isolation. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp > 1b3fb47d7567b5467fef2a2bb15d5c4a2ea42aa5 > 3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp > PRE-CREATION > 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp > 047778d05ebbbefd85e4a163dbb6ab8445edfb7f > > Diff: https://reviews.apache.org/r/11849/diff/ > > > Testing > ------- > > Added a test, however this test can be _significantly_ cleaned up were we to > create an abstraction for generating process trees! > > > Thanks, > > Ben Mahler > >
