Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist

[hyc@symas.com]

h.b.furuseth@usit.uio.no 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/