[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] deferred callbacks and evbuffer cleanup_cb



On Sun, Mar 20, 2016 at 4:36 PM, Azat Khuzhin <a3at.mail@xxxxxxxxx> wrote:
> On Sun, Mar 20, 2016 at 04:11:18PM +0100, Jan Heylen wrote:
>> On Sun, Mar 20, 2016 at 3:55 PM, Azat Khuzhin <a3at.mail@xxxxxxxxx> wrote:
>> > On Sun, Mar 20, 2016 at 03:11:31PM +0100, Jan Heylen wrote:
>> >> On Sun, Mar 20, 2016 at 3:01 PM, Azat Khuzhin <a3at.mail@xxxxxxxxx> wrote:
>
>> > Why do you need this special case evbuffer_write(), can you just use
>> > bufferevent_write_buffer() always?
>> In most cases, that would be overkill, as long as the fd/socket is not
>> overloaded, the data should go out immediately (so the data can be on
>> the stack of the function that was trying to send it, and no
>> 'memcpy'/malloc/data housekeeping has to happen at all)
>
> There is no memcpy/malloc since bufferevent_write_buffer() is
> evbuffer_add_buffer() and it only needs to copy *chains* (structures
> that contains pointer to your refs), of course maybe a one/two malloc's
> for chain itself, but does it critical for you?
Indeed, but we guarantee the user that he's free to do whatever to
pass to 'send', and if we need to 'postpone' the write, it's then we
will need to do a memcpy (to keep that guarantee).

>
>> > Since cleanup_cb must be called only when reference didn't exist,
>> > example:
>> >  struct evbuffer *buf = evbuffer_new();
>> >  evbuffer_add_reference(buf, data, len, cleanup, buf);
>> >  bufferevent_write_buffer(evbuf, buf);
>> >  evbuffer_free(buf);
>> > And during this calls "cleanup" will not be called because
>> > bufferevent_write_buffer() will take the chain ownership (part of
>> > evbuffer that contains you reference), so when you call evbuffer_free()
>> > there is no chain in evbuffer so "cleanup" will not be called yet.
>> Indeed, I know, the reason I want to use cleanup, suits my needs.
>
> You can also re-create buffer with cleanup callback if evbuffer_write()
> return an error, in this case you don't need special case in cleanup
> callback.
>
>> > "cleanup" will be called only when it will be drained from
>> > bufferevent_get_output() and it will happen only it will be written to
>> > the client, or I'm missing something and it doesn't work like this?
>> No, that is indeed what I was planning to do, but I thought I was
>> missing something, as these cleanup_cbs
>> didn't come with deferred thingy. At the moment I'm going to do this
>> without deferring. But I'll probably have to add that later.
>>
>> Btw, is there a reason why the deferral infrastructure is 'internal'?
>> Wouldn't it be useful as an extra interface of libevent? Especially
>> the deferral implementation of 2.1.x, where some issues with
>> priorities where solved I understood from the documentation. Or is
>> there a reason not to use it as a more 'generic' callback deferral
>> infrastructure?
>
> Once you export something you can't change it, or you have to support
> two versions (to avoid breaking binary compatibility), and besides
> nobody ask about this before (AFAIR).
Ok, understood :-)

>
> But we have finalizers (event_finalize()) and some parts (as you already
> mentioned) of library support them via flags (bufferevent/evbuffer).
I'll have to have a look at the finalizers. But on first sight, not
the same as deferred callbacks?
finalizers: "These functions are used to safely tear down an event in
a multithreaded application"

>
> Regards,
> Azat.
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.