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?
The write is happening immediately when I call bufferevent_write(). It's not being queued up for the event loop. It's happening synchronously in the context of the read handler that I'm currently in. Instead of:
- enter read handler
- do read handler stuff
- queue up write() for later event loop iteration
- exit read handler
- go back to event loop
- write occurs
- client sees the data
I see:
- enter read handler
- do read handler stuff
- execute write() back to client which succeeds in line
- client sees the data
- exit read handler
- go back to event loop
Like I said, I can work around this and force the write to occur in the next iteration of the event loop by using a 0 second timer event, I just wanted to make sure I wasn't missing something.
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()
Perfect. :)
Thanks for your responses!
- scott
|