> On July 18, 2016, 10:01 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, line 715
> > <https://reviews.apache.org/r/50163/diff/1/?file=1446203#file1446203line715>
> >
> > Let's pull out the side-effect and feed it to the check.
In retrospect it seems ok to in some cases to have side-effects within CHECKs,
mostly in the case of CHECK_NOTNULL:
```
evbuffer* buffer = CHECK_NOTNULL(evbuffer_new());
```
Because this reads well and will show the contents of the check
("evbuffer_new()") in the error message. However, pulling them out for add and
write_buffer does seem more readable to me:
```
CHECK_EQ(0, evbuffer_add(buffer, data, size));
CHECK_EQ(0, bufferevent_write_buffer(self->bev, buffer));
// vs
int result = evbuffer_add(buffer, data, size);
CHECK_EQ(0, result);
int result = bufferevent_write_buffer(self->bev, buffer);
CHECK_EQ(0, result);
```
So I'll pull them out for these two, but I'll use our CHECK_NOTNULL pattern.
Sound good?
> On July 18, 2016, 10:01 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, lines 714-715
> > <https://reviews.apache.org/r/50163/diff/1/?file=1446203#file1446203line714>
> >
> > I think it's ok to do a `CHECK` on the result of `evbuffer_add` if you
> > test `buffer` for `nullptr` first.
> > We should return a failure if the allocation failed though right?
For CHECK vs Failure, good question! I read their code and saw that the only
way that evbuffer_add can fail is in the case of us making a programming error,
or memory allocation failing. Also their documentation only makes a vague
mention of -1 on error, no error code mechanism is provided, and no error cases
are documented. :(
So it seems safe to CHECK that this doesn't fail since it's not an expected
run-time error.
> On July 18, 2016, 10:01 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, lines 735-736
> > <https://reviews.apache.org/r/50163/diff/1/?file=1446203#file1446203line735>
> >
> > Why `CHECK` vs `Failure`?
Ditto here w.r.t. not an expected run-time error: from reading their code it
seems this can only fail via a programmer error or a memory allocation failure.
If there were any other reasons I would have used a Failure indeed! Wish they
would document and return error codes.. :(
- Benjamin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50163/#review142646
-----------------------------------------------------------
On July 18, 2016, 9:40 p.m., Benjamin Mahler wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50163/
> -----------------------------------------------------------
>
> (Updated July 18, 2016, 9:40 p.m.)
>
>
> Review request for mesos, Joris Van Remoortere and Joseph Wu.
>
>
> Repository: mesos
>
>
> Description
> -------
>
> This function accidentally assumed that 'data' will live beyond the
> scope of the call, by using 'data' within an asynchronous context.
>
> This copies the data into an 'evbuffer' which will then get moved
> into the output buffer in the event loop. Note that this does not
> introduce an additional copy: we still have a single copy to get
> 'data' into the bufferevent output buffer.
>
> AFAICT, this bug is currently not triggered from any of the calling
> code because each call-site deletes the 'data' after the Future
> completes (it appears that the 'send_callback' will be executed
> *after* the call to bufferevent_write and after the output buffer
> is flushed).
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/src/libevent_ssl_socket.cpp
> 2e7f33241b5291593cac4ea4c8f0351c19f7f0c2
>
> Diff: https://reviews.apache.org/r/50163/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Benjamin Mahler
>
>
