mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Park" <mcyp...@gmail.com>
Subject Re: Review Request 37821: Join threads in libprocess when shutting down.
Date Thu, 10 Sep 2015 08:20:53 GMT

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


I've made a few nit comments below but I have some higher-level questions.

  (1) In this patch, when the destructor of `ProcessManager` is invoked we immediately start
to ignore messages. It's not obvious to me that this is necessary or desired. Could we just
enqueue the `TerminateEvent` by calling `process::terminate(process, false)`, let it race
against other messages that may be coming in, and ignore anything that arrives after `TerminateEvent`?
  (2) What are the implications of shutting down the event loop via `EventLoop::stop()`? This
would be useful to know to learn about the required order between process termination, event
loop shutdown, and thread pool joins.


3rdparty/libprocess/src/libev.cpp (line 30)
<https://reviews.apache.org/r/37821/#comment154722>

    Is there a reason why this was moved up? Seems like `async_shutdown` could've been added
below this, at its original location?



3rdparty/libprocess/src/process.cpp (line 382)
<https://reviews.apache.org/r/37821/#comment154727>

    The `const` here has no effect.



3rdparty/libprocess/src/process.cpp (lines 442 - 443)
<https://reviews.apache.org/r/37821/#comment154755>

    This fits in 1 line.



3rdparty/libprocess/src/process.cpp (lines 2119 - 2121)
<https://reviews.apache.org/r/37821/#comment154823>

    Could you explain why we want to start ignoring messages here?
    
    Below, we do `process::terminate(process, false);` which purposely does not inject the
`TerminateEvent` in order to allow the actor to process its queue.
    
    This is great, but wouldn't we be dropping messages that were sent between  `draining_queue.store(true);`
and when the `TerminateEvent` actually gets enqueued at the back? Is the decision that this
doesn't matter?



3rdparty/libprocess/src/process.cpp (line 2171)
<https://reviews.apache.org/r/37821/#comment154824>

    `s/int/long/`?


- Michael Park


On Sept. 8, 2015, 5:54 p.m., Greg Mann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37821/
> -----------------------------------------------------------
> 
> (Updated Sept. 8, 2015, 5:54 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Artem Harutyunyan, Joris Van Remoortere,
Joseph Wu, and Michael Park.
> 
> 
> Bugs: MESOS-3158
>     https://issues.apache.org/jira/browse/MESOS-3158
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Join threads in libprocess when shutting down.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/event_loop.hpp 36a4cd2b1ff59f6922173ad17115bf80cc3c8f30 
>   3rdparty/libprocess/src/libev.cpp 97a2694f9b10bc61841443b21f4f96055493e840 
>   3rdparty/libprocess/src/libevent.cpp ee7906470069b0391dde7cd685b1d4eb3a158c03 
>   3rdparty/libprocess/src/process.cpp 0e5394acff16376809918d583d7aee582cc6da54 
> 
> Diff: https://reviews.apache.org/r/37821/diff/
> 
> 
> Testing
> -------
> 
> After configuring with both "../configure" and "../configure --enable-libevent --enable-ssl":
> 
> make check
> 
> 
> Also, to check for race conditions related to the initialization/shutdown of libprocess,
try something like:
> 
> for n in {1..1000}; do echo $n; 3rdparty/libprocess/tests --gtest_filter=ProcessTest.Spawn;
done
> 
> 
> Thanks,
> 
> Greg Mann
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message