I went ahead and implemented the three callback methods related to threads
and used them and everything is working as expected now. The responses are
being sent to the browser immediately when I call the method. There is no
longer a problem here.
I still would like to know a little about how the underlying thread
architecture works, if anybody has time to explain. And why there would be
a 10s delay.
On Wed, Jun 20, 2012 at 9:09 AM, Julian Bui <julian...@gmail.com> wrote:
> Hi all,
>
> I am having trouble sending HTTP replies/responses in a timely manner
> using evhttp.
>
> PROBLEM:
> If I call evhttp_send_reply in the gencb (callback that handles all
> requests), then my requests are sent out in a timely manner and everything
> is fine. However, I do some processing that will take a while so I don't
> want do the processing in this callback because it will hold up the
> dispatch loop and I think I won't be able to accept any connections while
> I'm doing this slow processing. Instead, when I get a request, I store the
> evhttp_request* off, and then hand it to a thread, and then return from the
> gencb. Later, when the processing is done, the original request's
> evhttp_request* is retrieved and used to send the response. However, the
> browser doesn't receive the response until exactly 10.0s later after the
> evhttp_send_reply was invoked, everytime...unless I call evhttp_send_reply
> from the gencb in the dispatch loop thread, in which case the browser gets
> the response immediately.
>
> PSEUDOCODE:
>
> *Dispatch loop thread*
> ::onGeneralRequest { 1. Store the evhttp_request, 2. Hand off the request
> to a worker thread, 3. return }
>
> *Worker thread*
> // do work that might take a few seconds
> cout << "about to send reply" << endl;
> evbuffer* resp_buf = evbuffer_new();
> evbuffer_add_printf(resp_buf, "This is the body");
> evhttp_send_reply(response.conn, 200, "bogus reason", resp_buf); //
> use the original evhttp_request* (response.conn), send a success message
> cout << "sent reply" << endl; // at this point the browser still
> doesn't get the response, 10s in the future it will get it
>
> QUESTIONS:
>
> - Do I need to use evthread.h? I am using QThreads, part of the Qt
> library, so it looks like I need to implement and call three methods: 1)
> evthread_set_condition_callbacks, 2) evthread_set_id_callbacks, and 3)
> evthread_set_lock_callbacks. Do I just implement and call these methods
> and then everything will be fine? I don't need to tell the library to
> specifically use my custom threading library as long as I call these three
> methods? There's no other setup? After I set these methods all the
> threading/locking is transparent to me?
> - Why does it seem like I can't send the reply from a different
> thread? The variables I'm using are local to the particular request and
> are not shared, so I don't see why there should be any problem. In other
> words, I don't expect that there would be any race conditions since the
> requests are isolated from each other (?)
> - Any idea what this 10s delay is when I send the reply from a
> different thread?
>
>
> Any feedback would be greatly appreciated.
>
> Thanks,
> -Julian
>
