[Date Prev][Date Next]
Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
> - 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/