Re: [Libevent-users] async writes for bufferevent_write/bufferevent_write_buffer?

[Mark Ellzey <mthomas@xxxxxxxxxx>]

On Thu, Jul 18, 2013 at 10:52:06AM -0600, J. Scott Dorr wrote:
> 
> On Jul 18, 2013, at 9:59 AM, Mark Ellzey <mthomas@xxxxxxxxxx> wrote:
> > 
> > A little about deferred callbacks:
> > 
> > When you do something like bufferevent_write(), the actual underlying
> > protocol write is not executed immediately; it is queued up to be run in
> > the next iteration of the event loop. So if you do a sleep() in your
> > callback, you will not drop back to the main loop until you return.
> > Though even without the sleep, the write will not be done until the next
> > loop.
> 
> This was my expectation, but the fact that the client sees the echo'd hello before the sleep() finishes strongly suggests that the write is happening before going back to the event loop.
> The sleep() is only there to help me visualize the flow and the order in which things take place.
> 

Wait, so you see the write being done immediately? How is this not
async?

> > Another thing you must take into account is OpenSSL itself, and the way
> > it deals with non-blocking IO. A write to a non-blocking ssl socket can
> > return one of several different statuses. For example, SSL_write() can
> > return SSL_ERROR_WANT_READ. This means you have to stop writing, and
> > start reading. In order to reduce potential resource exhaustion, the
> > read is not done until the next iteration of the loop. Once that read
> > has succeeded, SSL_write() is attempted again.
> 
> I'm using the openssl support in libevent (which uses bufferevents to manage things).  I'm hoping these types of situations are handled under the covers as I don't believe I have visibility to that layer from the libevent side of things.
> 

Correct, it is. Which is why you won't always see an immediate
send()/recv()

> > A final thing you have to look at is how your operating system deals
> > with network IO. Say, for example, your operating system has TCP nagle
> > enabled, sending a small payload of "hello" may have a bit of latency
> > associated with it since nagle is going to wait for a set amount of time
> > for more data to buffer up into one packet.
> > 
> > In your test code above, I suggest turning off deferred. I would also
> > suggest using strace / dtruss if available to watch for read / write / recv /send.
> 
> I initially didn't use deferred callbacks.  I switched to deferred on the off chance it would force the write to happen in the next iteration of the event loop.
> 
> I can always queue up a 0-second event timer to invoke wrapper function that does the bufferevent_write() which will force it to be on the next iteration.
> 
> 

If you want write to happen in the next iteration, then deferred is what
you want.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.