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



src/master/master.hpp
<https://reviews.apache.org/r/7845/#comment28270>

    The ownership complexity comes from here. A 'Task*' is stored here AND in a 
Framework struct, but actually "owned" by the Master (that's who does new and 
delete). Perhaps a comment? At some point we should determine a way to 
eliminate this.



src/master/master.hpp
<https://reviews.apache.org/r/7845/#comment28271>

    A 'Task' is copyable and assignable, so we should just use a copy of 'Task' 
here (not a shared_ptr). This should simplify ownership.



src/master/master.hpp
<https://reviews.apache.org/r/7845/#comment28272>

    See above.



src/master/master.cpp
<https://reviews.apache.org/r/7845/#comment28274>

    By copying Task this comment becomes unnecessary.



src/master/master.cpp
<https://reviews.apache.org/r/7845/#comment28275>

    All this becomes unnecessary, we always delete task here.



src/slave/http.cpp
<https://reviews.apache.org/r/7845/#comment28260>

    &



src/slave/slave.hpp
<https://reviews.apache.org/r/7845/#comment28276>

    We'll still want to delete the tasks because we should not use shared_ptr 
with Task (see comments above and below).



src/slave/slave.hpp
<https://reviews.apache.org/r/7845/#comment28268>

    Ugh, 'launchedTasks' is such a bad name ... should be 'running' tasks. My 
bad. :(



src/slave/slave.hpp
<https://reviews.apache.org/r/7845/#comment28277>

    Copy like in master.



src/slave/slave.hpp
<https://reviews.apache.org/r/7845/#comment28267>

    Again, no need for shared_ptr here.



src/slave/slave.hpp
<https://reviews.apache.org/r/7845/#comment28265>

    Maybe a comment along the lines that this is deleting all the non-completed 
(i.e., still owned) pointers.



src/slave/slave.hpp
<https://reviews.apache.org/r/7845/#comment28264>

    s/the//



src/tests/master_tests.cpp
<https://reviews.apache.org/r/7845/#comment28262>

    If this sleep is really needed please include a comment why (so we can get 
an idea of what would need to be done to eliminate the sleep).


- Benjamin Hindman


On Nov. 3, 2012, 1:44 a.m., Ben Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/7845/
> -----------------------------------------------------------
> 
> (Updated Nov. 3, 2012, 1:44 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Vinod Kone.
> 
> 
> Description
> -------
> 
> We were allowing default constructors in the master / slave data structs, 
> which led to MESOS-303 when I added code that triggered copies.
> 
> So this change does the following to the structs:
>   -Explicitly disallow copying / assignment.
>   -Use circular_buffers of shared_ptrs to hold completed data.
>   -This allows us to remove the explicit deletes of the structs, and 
> transition the pointer ownership into the completed______ buffers instead.
> 
> Please take a close look, as some of the ownership semantics are tricky. 
> (esp. in the manipulation of Tasks in master).
> 
> 
> This addresses bug MESOS-303.
>     https://issues.apache.org/jira/browse/MESOS-303
> 
> 
> Diffs
> -----
> 
>   src/master/http.cpp 636fed772a93fdc4683216e8646189a5a436daa7 
>   src/master/master.hpp 1d8d0e4b0080d5efb25f8140e4a9bafdff513469 
>   src/master/master.cpp 8b6c71575d57816588a52dfc0fa74e51df1bea4d 
>   src/slave/http.cpp 2411e206839ec5d9a683e58e61b63b3b3ec6dc91 
>   src/slave/slave.hpp be0d7cc239e51636bb07e12c3046e0751a958787 
>   src/slave/slave.cpp 2bd2dbce538a6108dd9fe607829cfbdab33e0778 
>   src/tests/master_tests.cpp d9cd09c5650234351f570f0a035f4b61cd2d00f5 
> 
> Diff: https://reviews.apache.org/r/7845/diff/
> 
> 
> Testing
> -------
> 
> sudo make check
> 
> I ran a local run, with a long-lived-framework that I Ctrl+C'ed several 
> times. This should have caused completed tasks / executors / frameworks.
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Reply via email to