How about we do:

Shared<T> share(); -- in Owned<T>

and maybe even rename 'upgrade()' to 'own()' in Shared<T>!

Ben.


On Wed, Nov 6, 2013 at 9:17 AM, Jie Yu <[email protected]> wrote:

>
>
> > On Nov. 6, 2013, 6:48 a.m., Benjamin Hindman wrote:
> > > src/messages/log.proto, line 186
> > > <
> https://reviews.apache.org/r/14946/diff/6/?file=377561#file377561line186>
> > >
> > >     I think reusing the RecoverRequest for both the network broadcast
> and a RecoverProcess adds unnecessarily complexity. Why can't the
> RecoverProcess just use it's Shared<Replica> to explicitly ask the Replica
> to set update it's metadata?
> >
> > Jie Yu wrote:
> >     That was my initial solution. The problem is that you need to mark
> setState (or update) as a const function, which is OK because Replica is a
> wrapper anyway, but is not intuitive. What do you think?
> >
> >     Or we may want to introduce a WritableShared<T>(const Shared<T>&
> shared) to allow writing?
> >
> > Benjamin Hindman wrote:
> >     I guess I'm still unclear about the recovering semantics in the
> first place. What does it mean to have both a RecoverProcess and a
> CoordinatorProcess sharing a replica simultaneously? Can we not give the
> RecoverProcess an Owned<Replica> and then after it completes make it shared?
>
> Oh! Haven't thought about in this way. Yeah, that should work.
>
> We either need to add
> Shared(const Owned<T>& owned);  -- in Shared<T>
>
> or
> Shared<T> downgrade(); -- in Owned<T>
>
> Which one do you prefer?
>
>
> - Jie
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14946/#review28259
> -----------------------------------------------------------
>
>
> On Nov. 5, 2013, 12:52 a.m., Jie Yu wrote:
> >
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/14946/
> > -----------------------------------------------------------
> >
> > (Updated Nov. 5, 2013, 12:52 a.m.)
> >
> >
> > Review request for mesos and Benjamin Hindman.
> >
> >
> > Bugs: MESOS-736
> >     https://issues.apache.org/jira/browse/MESOS-736
> >
> >
> > Repository: mesos-git
> >
> >
> > Description
> > -------
> >
> > This is the last patch of a series of patches that implement catch-up
> replicated log.
> >
> > Here is summary of this patch:
> > 1) Introduced RecoverRequest/RecoverResponse in log.proto.
> > 2) Replaced Promise with ReplicaInfo in log.proto as we need persist
> recovery information (maintain backwards compatibility).
> > 3) A 2-phase empty log start-up algorithm.
> > 4) Added a test to test two competing recover processes.
> >
> > This is a joint work with Yan Xu.
> >
> >
> > Diffs
> > -----
> >
> >   src/Makefile.am 9780d07
> >   src/log/log.hpp 77edc7a
> >   src/log/recover.hpp PRE-CREATION
> >   src/log/recover.cpp PRE-CREATION
> >   src/log/replica.hpp d1f5ead
> >   src/log/replica.cpp 59a6ff3
> >   src/messages/log.proto 3d5859f
> >   src/tests/log_tests.cpp ff5f86c
> >
> > Diff: https://reviews.apache.org/r/14946/diff/
> >
> >
> > Testing
> > -------
> >
> > bin/mesos-tests.sh
> --gtest_filter=CoordinatorTest.*:ReplicaTest.*:LogTest.* --gtest_repeat=100
> >
> >
> > Thanks,
> >
> > Jie Yu
> >
> >
>
>

Reply via email to