mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <bmah...@apache.org>
Subject Re: Review Request 61069: Introduced an optimized fixed size last-in-first-out semaphore.
Date Wed, 26 Jul 2017 04:59:13 GMT

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




3rdparty/libprocess/src/run_queue.hpp
Line 111 (original), 116 (patched)
<https://reviews.apache.org/r/61069/#comment257012>

    Looks like this change introduces *and uses* the fixed size LIFO semaphore, can you clarify
that in the description?
    
    It's also not clear to me whether it's ok to use LIFO for the run queue waiters, my guess
is we don't have to guarantee anything there. Also, it would be great to understand why that's
faster, and also, why linux has a slower semaphore than what you saw on OS X, sounds surprising?


- Benjamin Mahler


On July 24, 2017, 1:58 a.m., Benjamin Hindman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61069/
> -----------------------------------------------------------
> 
> (Updated July 24, 2017, 1:58 a.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Bugs: MESOS-7798
>     https://issues.apache.org/jira/browse/MESOS-7798
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Introduced an optimized fixed size last-in-first-out semaphore.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/process.cpp b268cdad776a3ca2a87cbe60eb098bde2a70667c 
>   3rdparty/libprocess/src/run_queue.hpp 109c300b8292f109b699c096eff0c72d674f4f14 
>   3rdparty/libprocess/src/semaphore.hpp 01438838f67e2b3093d95d49931f72888955f11c 
> 
> 
> Diff: https://reviews.apache.org/r/61069/diff/1/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>


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