Mailing-List: contact mesos-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mesos-dev@incubator.apache.org
Content-Type: multipart/alternative;
 boundary="===============6076823379478082707=="
MIME-Version: 1.0
Subject: Re: Review Request: Added a TERMINATING process state to avoid
 filtering or
 enqueing events after process cleanup has begun.
From: "Benjamin Hindman" <benh@berkeley.edu>
To: "Vinod Kone" <vinodkone@gmail.com>
Cc: "mesos" <mesos-dev@incubator.apache.org>,
 "Benjamin Hindman" <benh@berkeley.edu>
Date: Thu, 14 Mar 2013 17:23:55 -0000
Message-ID: <20130314172355.1180.43975@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: "Benjamin Hindman" <noreply@reviews.apache.org>
References: <20130314171826.1181.46514@reviews.apache.org>
In-Reply-To: <20130314171826.1181.46514@reviews.apache.org>
Reply-To: "Benjamin Hindman" <benh@berkeley.edu>

--===============6076823379478082707==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


> On March 14, 2013, 5:18 p.m., Vinod Kone wrote:
> > third_party/libprocess/src/process.cpp, line 2787
> > <https://reviews.apache.org/r/9922/diff/1/?file=3D270476#file270476line=
2787>
> >
> >     Why the recursive lock? Looks like you want this because of the log=
ic you added in #2806? IIUC, this allows the follows:
> >     =

> >     --> terminate A
> >     --> A gets a recursive lock
> >     --> All its pending events are fired
> >     --> Enque of an event to A is called
> >     --> Recursive lock is acquired
> >     --> Enqueuing is skipped because process is in TERMINATING
> >     =

> >     If that is the case, what happens if =

> >     --> terminate A
> >     --> inside A->finalize() we do terminate B
> >     --> B has a pending event to A
> >     =

> >     Doesn't this cause a deadlock?
> =

> Benjamin Hindman wrote:
>     Calling process::terminate is asynchronous, so we won't cleanup B whi=
le we are cleaning up A.

And to be clear, we are not "firing" the pending events, just deleting them=
, which might cause discarded callbacks to get invoked on futures.


- Benjamin


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


On March 14, 2013, 7:25 a.m., Benjamin Hindman wrote:
> =

> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9922/
> -----------------------------------------------------------
> =

> (Updated March 14, 2013, 7:25 a.m.)
> =

> =

> Review request for mesos and Vinod Kone.
> =

> =

> Description
> -------
> =

> The change in https://reviews.apache.org/r/9916 was insufficient. Rather =
than continue along the lines of the previous fix this change effectively r=
everts the previous fix and instead adds a TERMINATING process state.
> =

> =

> This addresses bug MESOS-392.
>     https://issues.apache.org/jira/browse/MESOS-392
> =

> =

> Diffs
> -----
> =

>   third_party/libprocess/include/process/process.hpp 1433115516b2110acad0=
f5c2ee996dfb4203ba8b =

>   third_party/libprocess/src/process.cpp a1da05e83f24c4c94d4eef7ef0db6628=
86efee7a =

> =

> Diff: https://reviews.apache.org/r/9922/diff/
> =

> =

> Testing
> -------
> =

> ./bin/mesos-tests.sh --gtest_filter=3D"*.SchedulerExit" --gtest_repeat=3D=
1000
> =

> =

> Thanks,
> =

> Benjamin Hindman
> =

>


--===============6076823379478082707==--