You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mesos.apache.org by Benjamin Hindman <be...@berkeley.edu> on 2012/06/25 22:01:11 UTC

Review Request: Added io::read.

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

Review request for mesos and Jie Yu.


Description
-------

Useful for trying to read while handling spurious poll responses.


Diffs
-----

  third_party/libprocess/include/process/io.hpp 801a6d5 
  third_party/libprocess/src/process.cpp b7c181e 
  third_party/libprocess/src/tests.cpp 3d5005c 

Diff: https://reviews.apache.org/r/5567/diff/


Testing
-------

$ pwd
/path/to/libprocess/build
$ make check
...
$ ./tests
...


Thanks,

Benjamin Hindman

Re: Review Request: Added io::read.

Posted by Jie Yu <yu...@gmail.com>.

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



third_party/libprocess/src/process.cpp
<https://reviews.apache.org/r/5567/#comment18244>

    This is the newly introduced syntax? This is great as we don't need to create a separate process.
    
    However, what I am thinking is the lambda syntax is more dangerous than the defer syntax. My argument is: it is uncertain which process is going to invoke the lambda function (because the future callbacks are invoked in the process that sets the future, right?). Therefore, it is more prone to have race conditions. For instance, if the lambda function accesses some shared data, it is very likely that there are races on these shared data.
    
    Maybe we should warn the programmer to properly synchronize shared data in lambda functions?



third_party/libprocess/src/process.cpp
<https://reviews.apache.org/r/5567/#comment18245>

    What if we want to cancel this read operation? Can we just call future.discard() to cancel it?


- Jie Yu


On June 25, 2012, 8:01 p.m., Benjamin Hindman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5567/
> -----------------------------------------------------------
> 
> (Updated June 25, 2012, 8:01 p.m.)
> 
> 
> Review request for mesos and Jie Yu.
> 
> 
> Description
> -------
> 
> Useful for trying to read while handling spurious poll responses.
> 
> 
> Diffs
> -----
> 
>   third_party/libprocess/include/process/io.hpp 801a6d5 
>   third_party/libprocess/src/process.cpp b7c181e 
>   third_party/libprocess/src/tests.cpp 3d5005c 
> 
> Diff: https://reviews.apache.org/r/5567/diff/
> 
> 
> Testing
> -------
> 
> $ pwd
> /path/to/libprocess/build
> $ make check
> ...
> $ ./tests
> ...
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>