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? > > 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 [email protected] with unsubscribe libevent-users in the body.
