void *arg);
// evhttp will free bev after receiving BEV_EVENT_EOF
void evhttp_send_reply_bev(struct evhttp_request *req, int code, const char
*reason, struct bufferevent *bev);
I think that I like option 2 better.
Cliff
On Tue, May 10, 2011 at 11:36 PM, Cliff Frey wrote:
> So I like the idea of
>
> So I like the idea of getting read-by-read notification of data as it
> arrives. I'm not thrilled with the idea of changing default behavior
> wrt what counts as a read, though. Either a flag or another kind of
> callback would make me much more comfortable about the change here.
I will try
This looks awesome. Is it possible to add a regression test that triggers
the behavior?
On Mon, May 9, 2011 at 11:46 PM, Kevin Ko wrote:
> Hi,
>
> Patch in question:
> -
> Fix the case when failed evhttp_make_request() leaved request in the queue.
> -
> http://levent.git.sourceforge.net/git/g
I added tests, handled the infinite-receive case as well as the
infinite-send case, and slightly renamed a few things.
https://github.com/clifffrey/Libevent/tree/http-transfer-throttling
I believe that the changes there are enough to prevent out-of-memory
conditions when sending or receiving huge
> While I support these types of changes, I often wonder if the better
> solution to these problems is to gut the httpd API and create a more robust
> and abstracted replacement. *prepares for flogging*
>
> Libevent's http API was created for JIT services, not a apache/nginx/iis
> replacement. But
(apologies if this is a duplicate post)
It might be clearer to just look at my patches and commit messages
https://github.com/clifffrey/Libevent/commits/http_oom_prevention
But I've summarized my problems/fixes below. Please let me know if
you would rather I submit a github pull request, or a
