----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33295/#review81357 -----------------------------------------------------------
3rdparty/libprocess/src/process.cpp <https://reviews.apache.org/r/33295/#comment131702> For this synchronized block, and above: In order to ensure we don't end up in a deadlock: We should either: 1) make it clear that all virtual destructors of FirewallRules should never do a dispatch (i.e. async) 2) use a recursive mutex 3) take a copy of anything that could destroy in the synchronized block so that the destructor is delayed till after we exit the synchronized block - Joris Van Remoortere On April 22, 2015, 2:35 p.m., Alexander Rojas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/33295/ > ----------------------------------------------------------- > > (Updated April 22, 2015, 2:35 p.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, and Till Toenshoff. > > > Bugs: MESOS-2620 > https://issues.apache.org/jira/browse/MESOS-2620 > > > Repository: mesos > > > Description > ------- > > Introduces the interface `FirewallRule` which will be matched against > incoming connections in order to allow them to be served or being blocked. > For details, check the [design > doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit). > > > Diffs > ----- > > 3rdparty/libprocess/include/Makefile.am > 3da3e6cef1b5cb66c223425744d84741846ea730 > 3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION > 3rdparty/libprocess/include/process/process.hpp > 392c74df3e8a122aecd3633dffdeec4bcbd1f097 > 3rdparty/libprocess/src/process.cpp > 97ac09fd10b767bc46387abc3657d005a00830c8 > 3rdparty/libprocess/src/tests/process_tests.cpp > eb38edce2c483ba7f963a826893a15a075238618 > > Diff: https://reviews.apache.org/r/33295/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Alexander Rojas > >
