Jon Singler wrote:
Alex Evans wrote:
hello. I'm fairly new to libevent and especially evhttp, so I have a query
whose solution may just be 'dont use evhttp that way'... the summary is: how
can I know if an evhttp_request object is 'freed' behind my back, and avoid
using it after it's dead?
I'm writing a simple single threaded libevent based http server that
occasionally can't immediately respond to an incoming http request that has
been passed into a generic handler callback. instead it just saves the
evhttp_request pointer in my own list structure, and doesn't immediately
call evhttp_send_reply or equivalent. instead it falls back to the main
dispatch loop and lets other events happen.
some time later another event allows me to fill in a reply to the old
request, and so I call evhttp_send_reply on the stored request pointer.
my issue is, that looking at the http.c code there are a few ways that the
http_request I am storing a pointer to, could be freed. for example, if the
incoming connection to a server goes away, it deletes all the outstanding
requests. however my code won't get any notification that the connection or
requests have gone away, so I will merrily (later on) make use of the
request pointer after it's been freed.
what should I do? not use this pattern? use some callback mechanism I've
missed? worry less? or patch evhttp_request_free() to call an optional
callback?
I am just getting my feet wet with evhttp, but it seems to me that the
evhttp_connection_set_closecb would be useful. You can register a
callback so you're informed when a connection is closed, and you
should be able to tie that together with an outstanding request pretty
easily. That was what I was planning to do, at least.
I think that won't work at present. Receiving the connection close
callback does not mean the request will fail. Look at this code in
evhttp_connection_fail:
/* reset the connection */
evhttp_connection_reset(evcon); <- this calls the close cb
/* We are trying the next request that was queued on us */
if (TAILQ_FIRST(&evcon->requests) != NULL)
evhttp_connection_connect(evcon);
I know that Niels has written at least one HTTP proxy server with
evhttp (spybye), so he would presumably have faced this exact issue,
and I'd be surprised if his solution was to just live with things
exploding at random intervals.
At least when I last looked at SpyBye, I think it was more a proof of
concept than a totally complete and robust proxy implementation. IIRC it
didn't do keepalives, didn't stream responses (much less have any flow
control), so it would be somewhat slow and its memory usage could grow
arbitrarily large. A fine piece of work, but (as with so much software)
there's still work that could be done on it.
In general, I'm finding the evhttp stuff to be really well designed.
I've already had a few instances where I was trying to figure out how
to handle some aspect of implementing an HTTP server with evhttp where
I eventually figured out that I didn't have to do anything to handle
it, because evhttp took care of it for me, so hopefully this
contingency has also already been thought of and dealt with.
The authorities seem to be away on holiday (I'm still waiting for a
response to my question about why libevent forbids HTTP clients from
using a Content-Encoding header), but perhaps when they return they
will enlighten us as to the proper strategies.
It's a nice library (or I wouldn't be using it), but I have found (and
fixed) several bugs and limitations.
-Jon
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
