> On Nov. 18, 2014, 4:29 p.m., Dominic Hamon wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 1643 > > <https://reviews.apache.org/r/28196/diff/2/?file=768245#file768245line1643> > > > > foreach? > > Joris Van Remoortere wrote: > I played around with foreach to test whether it is safe under container > modification (for example if inside the loop we add an element). It did not > seem to be robust to this behavior. > Since during the loop we call arbitrary code I thought it would be safest > to assume someone could modify the container during one of these callbacks. > The manual counting is robust to container modification. > > I understand that currently this is not possible as we change the state > before calling the callbacks. This may change in the future if we want to > enforce a strict order of execution. I did this mostly to prevent an ugly > debugging session for someone in the future. > Does that make sense?
Yep. Same reason you can't cache the return of .size(). A c++11 for range loop, though... Sigh. - Dominic ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28196/#review62070 ----------------------------------------------------------- On Nov. 18, 2014, 4:06 p.m., Joris Van Remoortere wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28196/ > ----------------------------------------------------------- > > (Updated Nov. 18, 2014, 4:06 p.m.) > > > Review request for mesos, Benjamin Hindman, Dominic Hamon, Niklas Nielsen, > and Timothy Chen. > > > Bugs: MESOS-2126 > https://issues.apache.org/jira/browse/MESOS-2126 > > > Repository: mesos-git > > > Description > ------- > > Use std::vector instead of std::queue to reduce dynamic allocations and > improve performance. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/future.hpp > 2e4f9efe53e2e9966f23bd516e61fd9d83ed6b33 > > Diff: https://reviews.apache.org/r/28196/diff/ > > > Testing > ------- > > make check > valgrind 3rdparty/libprocess > (previous) total heap usage: 272,452 allocs, 271,410 frees, 56,981,783 bytes > allocated > (new) total heap usage: 188,837 allocs, 188,111 frees, 28,694,829 bytes > allocated > 3rdparty/libprocess/benchmarks throughput improved ~78% > > > Thanks, > > Joris Van Remoortere > >
