Hi Anton, Thanks for your response. As to the force option, I understand we need to clean up the connection, but how is the dead connection case different that any other time we are cleaning up a connection? If we don't force (this is what I've currently implemented) the connection will still be correctly cleaned up when the refcount drops to zero as any other references in the in-flight requests are cleaned up, no?
I'm testing force == 0 in the cleanup and it seems to work fine with no obvious handle or memory leaks. Travis On Aug 15, 6:14 pm, Anton Bobrov <[EMAIL PROTECTED]> wrote: > BeeOnRope wrote: > > I'd like to submit a patch for this issue, but I'd like advice on the > > correct way to fix it. Suggestion 1 is to simple remove the "force" > > option on the connection_free call - why are we using it this > > context? Is there some reason to ignore the refcount here? This fix > > yes, coz we need to get rid of that dead connection in case of reconnect > and there seems to be no simple and elegant way but force free/close it. > > > is easy and seems "correct" to me. Suggestion 2, if there is some > > reason to keep this force behavior, is to add code in the force case > > that locks the request list and iterates though it looking for > > references to the connection to be freed and removing them (NULLing > > them out) - thus we won't try to access them in the connection lost > > code, above. > > that seems like the way to go to me. i think its best to address this > inside nsldapi_handle_reconnect, a loop just like you have mentioned, > right above nsldapi_free_connection(), holding LDAP_REQ_LOCK as well, > iterating and cleaning up. _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
