> On Nov. 5, 2014, 8:44 p.m., Benjamin Hindman wrote:
> > src/slave/containerizer/fetcher.hpp, line 64
> > <https://reviews.apache.org/r/27516/diff/3/?file=747421#file747421line64>
> >
> >     Mind replacing '> >' with '>>' everywhere in your patch please? Thanks!

So we are now only using C++ compilers that do not have this bug any more? 
Nice! (Only about 12000 other places in Mesos to fix then :-)


> On Nov. 5, 2014, 8:44 p.m., Benjamin Hindman wrote:
> > src/slave/containerizer/fetcher.cpp, line 19
> > <https://reviews.apache.org/r/27516/diff/3/?file=747422#file747422line19>
> >
> >     Please put "" includes after <> includes.

Actually, there should only be "" includes here, according to this: 
http://mesos.apache.org/documentation/latest/mesos-c++-style-guide/, which 
references this: 
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Names_and_Order_of_Includes

And yes, the order needs to be swapped then, too. First the header that matches 
the cpp file, then the rest.  

20 minutes later:

Just noticed that in all the places I looked we are NOT following the stated 
style guide in this regard. Hm. Switching back to my original order then.


> On Nov. 5, 2014, 8:44 p.m., Benjamin Hindman wrote:
> > src/slave/containerizer/fetcher.cpp, line 112
> > <https://reviews.apache.org/r/27516/diff/3/?file=747422#file747422line112>
> >
> >     Even after making the change above, we shouldn't close the passed in 
> > file descriptors. The comment for this function also says that we dup the 
> > file descriptors, which implies that we won't be closing them because we're 
> > creating our own copy so we can control our copy's lifetime.
> >     
> >     In general, the semantics that I've seen compose well are always 
> > dup'ing the descriptors ourselves (if we want them to outlive the function 
> > call) and then letting the caller close any file descriptors they passed in 
> > on their own accord. It's much easier to reason about file descriptor 
> > lifetimes with these semantics.
> >     
> >     Even better would be to have an FD abstraction that does reference 
> > counting, but unfortunately we don't have one of those yet.

Agree. I was a little surprised myself to see this done otherwise, but did not 
want to argue.


> On Nov. 5, 2014, 8:44 p.m., Benjamin Hindman wrote:
> > src/slave/containerizer/mesos/containerizer.cpp, line 524
> > <https://reviews.apache.org/r/27516/diff/3/?file=747423#file747423line524>
> >
> >     Why does this need to be a Future? It looks like you're chaining this 
> > below via a 'then', which means you can just use Option<int> since a 'then' 
> > only invokes this if the Future is ready. The fact that you're always doing 
> > a 'get()' on the future too implies this precondition.

If we made it a plain Option<int> then that value would have to be present at 
the time fetcher::run() returns. This would mean we have to block in 
fetcher::run() to wait for the fetcher.


- Bernd


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27516/#review60098
-----------------------------------------------------------


On Nov. 3, 2014, 8:36 a.m., Bernd Mathiske wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27516/
> -----------------------------------------------------------
> 
> (Updated Nov. 3, 2014, 8:36 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1316
>     https://issues.apache.org/jira/browse/MESOS-1316
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Manually rebasing and re-editing https://reviews.apache.org/r/21233/, which 
> is supposed to be replaced now by this patch. 
> 
> Original description: "To test the mesos-fetcher (and the setting of the 
> environment) more cleanly I did some refactoring into a 'fetcher' namespace."
> 
> Also moved fetcher environment tests to fetcher test file. Added two fetcher 
> tests.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am e6a07150c10b9fa040143e394b2f913a18eeebc1 
>   src/launcher/fetcher.cpp 9323c28237010fa065ef34d74435c151ded530a8 
>   src/slave/containerizer/fetcher.hpp PRE-CREATION 
>   src/slave/containerizer/fetcher.cpp PRE-CREATION 
>   src/slave/containerizer/mesos/containerizer.cpp 
> d4b08f54d6feb453f3a9d27ca54c867176e62102 
>   src/tests/containerizer_tests.cpp 2c90d2fc18a3268c55b6dfe98699bfb36d093983 
>   src/tests/fetcher_tests.cpp d7754009a59fedb43e3422c56b3a786ce80164aa 
> 
> Diff: https://reviews.apache.org/r/27516/diff/
> 
> 
> Testing
> -------
> 
> make check on Mac OS 10.10 and Ubuntu 14.4.
> 
> In total, 3 tests fail: ExamplesTest.NoExecutorFramework, 
> ExamplesTest.JavaFramework
> , ExamplesTest.PythonFramework. It is strongly suspected that those are 
> unrelated to this code change and just generally flaky.
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Reply via email to