[Date Prev][Date Next]
RE: Overlay and overlaying (Was: SLAPI support is a pain)
> -----Original Message-----
> From: Pierangelo Masarati [mailto:firstname.lastname@example.org]
> Talking about overlay and overall architecture, I'm finally
> back from my "sabbatic" and I'd like to address a couple of
> things (as oon as I re-get in touc with HEAD code).
> I couldn't have overlay to work, so I digged into it and I
> had to fix or change a couple of things. I dont know if
> anybody found it, so I'll commit my fixs soon for review
> (or I'd rather pot a diff, so you can review before commit).
Whatever is convenient...
> Moreover, I found out that to support stacked callbacks we'd
> need to deal with automtically/dynamically allocated data in
> a reliable way. After some unsuccesful tries, the best I could
> figure out was a set of flags to say what data is temporary,
> and thus can be freed if not neded any more, and what's
> read-only, and thus a copy is to be made before massaging.
> I came into this while writing a dn massage overlay, which
> needs to massge entry's dn (and sometimes some attributes),
> while entries are usually read-only (but are not, for instance,
> when returned by back-ldap).
> I think this is also a problem for SLAPI, which in many cases,
> for "binary" compatibility, must rerrange data in "legacy"
> structures, or copy them for no sake.
Yes, SLAPI does a lot of copying.
> My approach would reuire to add (to the response structure,
> SlapReply, or to the entry itself) a flag/set of flags, and
> use them consistntly in overlays and when returning entries.
Sounds like a good thing for the SlapReply.
> I first considered adding flags in SlapReply that states
> whether some of its data is to be freed or not (e.g. error
> mssages and so, when replaced by other, more appropriate
> messages along the stack); but then I ran into the problem
> of how to free them: some of the mssages are allocated by
> ch_* routines, some on *ctx routines, some on LDAP_MALLOC()
> or even on LBER_MALLOC(). I know using free() usually does
> the job, but i really lost insight into memory allocation.
> Some handbook or giudelines would definitely help.
I tend to ignore the difference between LDAP_MALLOC and LBER_MALLOC since
they're #defined to ber_memalloc anyway. Also ch_* calls ber_*. The fact that
all the OpenLDAP code used a single malloc() function is pretty essential I
think. Certainly it would quit working on Windows if that were not true.
So the added complication is the sl_* functions for slapd's thread-local
storage. The sl_* and ch_* functions will check ownership of a memory region
and call each other's free() routines as needed, so usually it's safe to mix
them up. It's not safe to call ber_memfree() directly on sl_malloc'd memory;
that will cause a crash.
By the way, welcome back...
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support