> On March 17, 2014, 7:28 p.m., Dominic Hamon wrote: > > 3rdparty/libprocess/include/process/subprocess.hpp, line 79 > > <https://reviews.apache.org/r/19259/diff/2/?file=520575#file520575line79> > > > > Is there a reason this is restricted to void() methods only? > > Till Toenshoff wrote: > What should happen if that method returned something? I briefly thought > about using a bool instead and return if that was false. Would that be > something you preferred?
perhaps this should mimic the child function used in clone() on Linux, which returns int - Ian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19259/#review37433 ----------------------------------------------------------- On March 16, 2014, 11:05 a.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19259/ > ----------------------------------------------------------- > > (Updated March 16, 2014, 11:05 a.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, Dominic Hamon, and > Ian Downes. > > > Bugs: MESOS-1102 > https://issues.apache.org/jira/browse/MESOS-1102 > > > Repository: mesos-git > > > Description > ------- > > Adds the ability to process::subprocess to run a function (lambda) within the > child context, after fork and before exec. > > NOTE: Such lambda must not contain any async unsafe code. For details on > async safety, see POSIX.1-2004 on async-signal-safe functions, also > referenced in the signal man-pages: > http://man7.org/linux/man-pages/man7/signal.7.html. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/subprocess.hpp > d16cbc1e3d464e1784f116ccdb327cf0784f07c2 > 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION > 3rdparty/libprocess/src/tests/subprocess_tests.cpp > d15d4d159105474117c4ea432b215431209ab539 > > Diff: https://reviews.apache.org/r/19259/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Till Toenshoff > >
