Johan Jakus writes:
To be sure, when I use entry_dub(); it makes a duplication of the entry from the server cache to somewhere in the memory. So I just need to make the pointer of the SlapReply point to my new duplicated entry,
...and dispose of the old entry according to rs->sr_flags, and reset the entry-related sr_flags so they do not get applied to the new entry. Which is why it's better to let rs_entry2modifiable() & co maintain rs->sr_entry. Note that a lot of old overlay code also got this wrong. We've cleaned up most of it recently.
modified it as wanted,and free it once the response have been send to the client.
If you want to free the entry yourself, instead you can do
rs_replace_entry(entry_dup(rs->sr_entry));
or the equivalent
e = entry_dup(rs->sr_entry); rs_flush_entry(rs); /* Obey and clear REP_ENTRY_MUST<BEFREED/RELEASE> */ rs->sr_entry = e;
Now your overlay owns the entry and should free it, other modules will not do that. If you won't touch your entry other than freeing once you send it, you may also want to make it modifiable so other overlays can use it instead of doing another entry_dup():
rs->sr_flags |= REP_ENTRY_MODIFIABLE;
Do not keep any pointers into the entry in that case, since they may get invalidated by later overlays.
You can look at these functions in slapd/result.c to see how these flags work. Ignore all the asserts.
If, I'm multi-threading and an other request arrives it will use the entry still in the cache and not my modified duplication, is that write?
Yep.