On Jul 18, 2013, at 10:57 AM, Mark Ellzey <[email protected]> wrote:
> On Thu, Jul 18, 2013 at 10:52:06AM -0600, J. Scott Dorr wrote: >> >> On Jul 18, 2013, at 9:59 AM, Mark Ellzey <[email protected]> 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
