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?
(Oops; resending with the list cced)
I believe you are exactly right and that this is an evhttp bug/API
design flaw.
I've been working (off and on) on code with the same problem. It's a
proxy server which streams results from the upstream (to which it acts
as a client) to the downstream (to which it acts as a server). Thus, it
also can't immediately respond to the downstream's request and has this
window in which it assumes the evhttp_requests will not go away.
Sometimes they do, and it crashes or at least behaves oddly. (In
fairness, I'm not 100% sure this happens without some of the patches
I've been working on, but I think it would.)
My first thought was that evhttp should track whether calling code is
using a particular request (e.g., either it was created by the caller
for client requests or evhttp has called a callback but not received a
completed response) and send a callback indicating error. I haven't
implemented this, and definitely won't for at least a week. (I'm on
vacation, and my code's inaccessible from here.)
Besides the usual reasons for the connection being closed, the evhttp
server code incorrectly interprets it as a connection close when it
receives a pipelined request. Depending on what clients you have, that
might be one reason you're encountering errors.
any help or advice greatly appreciated. many thanks
Alex
Please consider the environment before printing this email :-)
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the sender immediately then
delete this email.
Media Molecule Limited
Company Reg No 5665849
Registered in England.
_______________________________________________
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
