> On Nov. 19, 2014, 12:29 a.m., Dominic Hamon wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 1643 > > <https://reviews.apache.org/r/28196/diff/2/?file=768245#file768245line1643> > > > > foreach?
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? - Joris ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28196/#review62070 ----------------------------------------------------------- On Nov. 19, 2014, 12:06 a.m., Joris Van Remoortere wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28196/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2014, 12:06 a.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 > >
