On Fri, Feb 25, 2011 at 10:38 AM, Christophe Fillot <[email protected]> wrote: > Hello, > > The following patch allows to delete a RPC pool (with evrpc_pool_free()), > including > all requests which have already started. The user-defined callback is called > with > a new status (EVRPC_STATUS_ERR_ABORTED) which allows to properly release > memory > used for message requests and replies. > > It also fixes some possible memory leaks in evrpc_schedule_request(), when > an error > is encountered. The problem I described in my previous message should also > be fixed. > > I checked different scenarios (with or without hooks, timeouts, connection > failures...) using Valgrind, everything seems ok. The "regress" test code > seems > also fine (all tests are OK). > > Please let me know your opinion about it, I'm not yet familiar with the > libevent > code :)
It looks plausible, though I haven't had a chance to review it too closely yet. I would like to have unit tests for this particular case too, if at all possible. One thing to watch out for in this code is the fact that the "next" pointer in the request is apparently used for keeping track of the request's neighbors on any of the requests list and the started_requests list, so it's important to make sure when adding a request to one of these lists, it isn't already on the other one. (I'm not sure whether the code already makes sure of this; I wish the existing evprc code were better about documenting its invariants.) The new "aborted" status code makes me slightly twitchy. Adding a new status code like this means that, potentially, old callbacks that don't know about the new callback will stop working. I think that it's okay in this one case, since the only way to get the new status code (if I'm understanding you right) is to free an evrpc instance with multiple pending requests, which would not have worked before at all... so no previously working code will break, which would make a new code okay. yrs, -- Nick *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
