> 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 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. 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. -Jon _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
