> On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp, line 55 > > <https://reviews.apache.org/r/11849/diff/1/?file=304305#file304305line55> > > > > why the include here?
os.hpp is a catch-all include if one wishes to include everything under os/*. > On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp, line 1 > > <https://reviews.apache.org/r/11849/diff/1/?file=304306#file304306line1> > > > > Are you missing the corresponding Makefile change? Thanks! > 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. > > Ben Mahler wrote: > 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. Alright, fixed! > On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp, lines > > 115-118 > > <https://reviews.apache.org/r/11849/diff/1/?file=304306#file304306line115> > > > > ditto. SIGCONT is only sent once to each pid. > On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp, line 285 > > <https://reviews.apache.org/r/11849/diff/1/?file=304307#file304307line285> > > > > close(grandChildPipes[0]) ? It's already closed..? > On June 12, 2013, 11:43 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp, line 414 > > <https://reviews.apache.org/r/11849/diff/1/?file=304307#file304307line414> > > > > immediately after forking :) fixed - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11849/#review21824 ----------------------------------------------------------- On June 18, 2013, 4:42 a.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11849/ > ----------------------------------------------------------- > > (Updated June 18, 2013, 4:42 a.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/Makefile.am > 2b7ee9c099a28dc5e482d7609e6307f2b6398e8b > 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 > 73b2336e93d6e5aac97e2c18e8e36c258c56a420 > > 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 > >
