On Sun, Mar 20, 2016 at 10:58:34AM +0100, Jan Heylen wrote: > Hi, > > I'm trying to use evbuffers, cleanup_cb, and the deferred callbacks. > > some background: > * using (tcp) sockets > * sending data over the socket: in first place try to write > (evbuffer_write), if you get 'wouldblock' postpone the write by using > bufferevent_write_buffer. Main reason is we don't need to keep the > user's data in most cases and the dat is send immediatly. > * after sending data, a 'send cb' should be called to the user who > wanted to send something. > > Now, when looking at the best way to get the cleanup happening (and a > mechanism to let the user know his data is send), I was looking at > both evbuffer callbacks and the evbuffer cleanup_cb. > I'm thinking on using the cleanup_cb, as it is only called when the > chain, the actual data, gets freed, so I can be sure the data is out. > With evbuffer callbacks, the original evbuffer gets drained upon call > to bufferevent_write_buffer already, and not when the data itself is > really 'out', so that means, I have to make a distinction.
Hi Jan, bufferevent_write() just move data from user-passed to bufferevent internal, you can get internal output buffer with bufferevent_get_output() > However, If I look at the code, these cleanup_cbs are not and cannot > be 'deferred'. So in the first place, when using evbuffer_write, the > cleanup_cb will happen on the stack, and so also my 'data is send' > callback, would happen on stack (and so cb will happen before the > sending data function returns). > > Questions: > * thinking about the 2 different paths on getting data out, > (evbuffer_write and postponed via bufferevent_write_buffer), what > would be the best mechanism to get the 'all data is out' cb mechanism > working for them both? > * Is it a design choice to not defer the cleanup_cb, or would it make > sense to add it? I suppose that the answer is: nobody need it until now. Cheers, Azat. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
