> On April 14, 2016, 7:10 p.m., Joseph Wu wrote: > > 3rdparty/libprocess/src/process.cpp, lines 489-490 > > <https://reviews.apache.org/r/45996/diff/1/?file=1338532#file1338532line489> > > > > This is now effectively managed by the `ProcessManager`, so you could > > bring it into the `ProcessManager` 's scope (which would still be global).
This makes sense (and I would love to eliminate all the global state in libprocess), but AFAICS it won't be easy to implement: if we make `gc` a field of `ProcessManager`, we'd ideally like to initialize and spawn the GC process in `ProcessManager`'s constructor. But that isn't possible, because we can't safely call `spawn` at the time we are constructing the ProcessManager. We could still move `gc` to be a field of `ProcessManager` but spawn it separately, but I'm not sure if that is actually a net improvement at that point. - Neil ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45996/#review128956 ----------------------------------------------------------- On April 11, 2016, 1:41 a.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/45996/ > ----------------------------------------------------------- > > (Updated April 11, 2016, 1:41 a.m.) > > > Review request for mesos and Joris Van Remoortere. > > > Bugs: MESOS-5144 > https://issues.apache.org/jira/browse/MESOS-5144 > > > Repository: mesos > > > Description > ------- > > Fixed memory leak of `gc` in `finalize()` in libprocess. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/gc.hpp > 799468ebe49f2a49d325f40ffd8acea727abf74c > 3rdparty/libprocess/src/process.cpp > 5e9dcfdc52f3a8223bc43af149b8e1f5dbdf5b0a > > Diff: https://reviews.apache.org/r/45996/diff/ > > > Testing > ------- > > > Thanks, > > Neil Conway > >
