[EMAIL PROTECTED] wrote: > - REP_ENTRY_MUSTRELEASE and REP_ENTRY_MUSTBEFREED: > > Callers that set these flags when sending an entry, *allow* the > callee to release/free rs->sr_entry. > Callers cannot depend on it being release/freed, but some do anyway. > > It should simplify things to make the send functions always obey > this flag, but I'm not sure how much cleanup that requires. > There is partial code for that in slap_send_search_entry(), along > with a FIXME note. > > Free MUSTBEFREED-entries with entry_free(), and MUSTRELEASE-entries > with be_entry_release_r(). There is no "use be_entry_release_w()" > flag, but no OpenLDAP code sends write-locked entries anyway.
I have the feeling that MUSTBEFREED and MUSTRELEASE should be consolidated into a single flag. be_entry_release_r() should simply call entry_free() if e->e_private is NULL. > + REP_ENTRY_MUSTRELEASE: > > Created for ITS#3671 to ensure that network hangs don't delay > cache entry unlocks: > > Modules should release their cache entry locks before sending > anything. They can't do that with cached entries they send in > rs->sr_entry, so instead they should set REP_ENTRY_MUSTRELEASE. > Conversely, anything which does network I/O (and other potentially > slooow ops I guess) should first obey this flag. > > Several overlays don't obey, nor some other code for sending an > entry when it decides to send an error response instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
